- 09 May, 2001 2 commits
-
-
Tom Lane authored
between index order and table order.
-
Tom Lane authored
collected by ANALYZE. Also, add some modest amount of intelligence to guesses that are used for varlena columns in the absence of any ANALYZE statistics. The 'width' reported by EXPLAIN is finally something less than totally bogus for varlena columns ... and, in consequence, hashjoin estimating should be a little better ...
-
- 07 May, 2001 1 commit
-
-
Tom Lane authored
a separate statement (though it can still be invoked as part of VACUUM, too). pg_statistic redesigned to be more flexible about what statistics are stored. ANALYZE now collects a list of several of the most common values, not just one, plus a histogram (not just the min and max values). Random sampling is used to make the process reasonably fast even on very large tables. The number of values and histogram bins collected is now user-settable via an ALTER TABLE command. There is more still to do; the new stats are not being used everywhere they could be in the planner. But the remaining changes for this project should be localized, and the behavior is already better than before. A not-very-related change is that sorting now makes use of btree comparison routines if it can find one, rather than invoking '<' twice.
-
- 25 Apr, 2001 1 commit
-
-
Tom Lane authored
Without this, it was making some pretty silly decisions about whether an expensive sub-SELECT should be the inner or outer side of a join...
-
- 22 Mar, 2001 1 commit
-
-
Bruce Momjian authored
-
- 16 Feb, 2001 1 commit
-
-
Tom Lane authored
relations. It's not very bright, but at least it now knows that A LEFT JOIN B must produce at least as many rows as are in A ...
-
- 15 Feb, 2001 1 commit
-
-
Tom Lane authored
-
- 24 Jan, 2001 1 commit
-
-
Bruce Momjian authored
-
- 12 Dec, 2000 1 commit
-
-
Tom Lane authored
avoid repeated evaluations in cost_qual_eval(). This turns out to save a useful fraction of planning time. No change to external representation of RestrictInfo --- although that node type doesn't appear in stored rules anyway.
-
- 05 Oct, 2000 1 commit
-
-
Bruce Momjian authored
Fix misspelling of disbursion to dispersion.
-
- 29 Sep, 2000 1 commit
-
-
Tom Lane authored
(Don't forget that an alias is required.) Views reimplemented as expanding to subselect-in-FROM. Grouping, aggregates, DISTINCT in views actually work now (he says optimistically). No UNION support in subselects/views yet, but I have some ideas about that. Rule-related permissions checking moved out of rewriter and into executor. INITDB REQUIRED!
-
- 18 Jun, 2000 1 commit
-
-
Tom Lane authored
materialized tupleset is small enough) instead of a temporary relation. This was something I was thinking of doing anyway for performance, and Jan says he needs it for TOAST because he doesn't want to cope with toasting noname relations. With this change, the 'noname table' support in heap.c is dead code, and I have accordingly removed it. Also clean up 'noname' plan handling in planner --- nonames are either sort or materialize plans, and it seems less confusing to handle them separately under those names.
-
- 31 May, 2000 1 commit
-
-
Peter Eisentraut authored
That means you can now set your options in either or all of $PGDATA/configuration, some postmaster option (--enable-fsync=off), or set a SET command. The list of options is in backend/utils/misc/guc.c, documentation will be written post haste. pg_options is gone, so is that pq_geqo config file. Also removed were backend -K, -Q, and -T options (no longer applicable, although -d0 does the same as -Q). Added to configure an --enable-syslog option. changed all callers from TPRINTF to elog(DEBUG)
-
- 30 May, 2000 2 commits
-
-
Tom Lane authored
fmgr_faddr() in favor of new-style calls. Lots of cleanup of sloppy casts to use XXXGetDatum and DatumGetXXX ...
-
Bruce Momjian authored
-
- 18 Apr, 2000 1 commit
-
-
Tom Lane authored
table for an average of NTUP_PER_BUCKET tuples/bucket, but cost_hashjoin was assuming a target load of one tuple/bucket. This was causing a noticeable underestimate of hashjoin costs.
-
- 12 Apr, 2000 1 commit
-
-
Bruce Momjian authored
-
- 09 Apr, 2000 1 commit
-
-
Tom Lane authored
-
- 30 Mar, 2000 1 commit
-
-
Tom Lane authored
to next integer. Previously, if selectivity was small, we could compute very tiny scan cost on the basis of estimating that only 0.001 tuple would be fetched, which is silly. This naturally led to some rather silly plans...
-
- 22 Mar, 2000 1 commit
-
-
Tom Lane authored
costs using the inner path's parent->rows count as the number of tuples processed per inner scan iteration. This is wrong when we are using an inner indexscan with indexquals based on join clauses, because the rows count in a Relation node reflects the selectivity of the restriction clauses for that rel only. Upshot was that if join clause was very selective, we'd drastically overestimate the true cost of the join. Fix is to calculate correct output-rows estimate for an inner indexscan when the IndexPath node is created and save it in the path node. Change of path node doesn't require initdb, since path nodes don't appear in saved rules.
-
- 14 Mar, 2000 1 commit
-
-
Tom Lane authored
of tuples we are going to retrieve from a sub-SELECT. Must have been half asleep when I did this code the first time :-(
-
- 15 Feb, 2000 1 commit
-
-
Tom Lane authored
accesses versus sequential accesses, a (very crude) estimate of the effects of caching on random page accesses, and cost to evaluate WHERE- clause expressions. Export critical parameters for this model as SET variables. Also, create SET variables for the planner's enable flags (enable_seqscan, enable_indexscan, etc) so that these can be controlled more conveniently than via PGOPTIONS. Planner now estimates both startup cost (cost before retrieving first tuple) and total cost of each path, so it can optimize queries with LIMIT on a reasonable basis by interpolating between these costs. Same facility is a win for EXISTS(...) subqueries and some other cases. Redesign pathkey representation to achieve a major speedup in planning (I saw as much as 5X on a 10-way join); also minor changes in planner to reduce memory consumption by recycling discarded Path nodes and not constructing unnecessary lists. Minor cleanups to display more-plausible costs in some cases in EXPLAIN output. Initdb forced by change in interface to index cost estimation functions.
-
- 07 Feb, 2000 1 commit
-
-
Tom Lane authored
fields in JoinPaths --- turns out that we do need that after all :-(. Also, rearrange planner so that only one RelOptInfo is created for a particular set of joined base relations, no matter how many different subsets of relations it can be created from. This saves memory and processing time compared to the old method of making a bunch of RelOptInfos and then removing the duplicates. Clean up the jointree iteration logic; not sure if it's better, but I sure find it more readable and plausible now, particularly for the case of 'bushy plans'.
-
- 26 Jan, 2000 1 commit
-
-
Bruce Momjian authored
* Portions Copyright (c) 1996-2000, PostgreSQL, Inc to all files copyright Regents of Berkeley. Man, that's a lot of files.
-
- 23 Jan, 2000 1 commit
-
-
Tom Lane authored
selectivity estimation wasn't right. This is better...
-
- 22 Jan, 2000 1 commit
-
-
Tom Lane authored
pghackers discussion of 5-Jan-2000. The amopselect and amopnpages estimators are gone, and in their place is a per-AM amcostestimate procedure (linked to from pg_am, not pg_amop).
-
- 09 Jan, 2000 1 commit
-
-
Tom Lane authored
code cleanup; no major improvements yet. However, EXPLAIN does produce more intuitive outputs for nested loops with indexscans now...
-
- 23 Nov, 1999 1 commit
-
-
Bruce Momjian authored
-
- 22 Aug, 1999 1 commit
-
-
Tom Lane authored
and fix_opids processing to a single recursive pass over the plan tree executed at the very tail end of planning, rather than haphazardly here and there at different places. Now that tlist Vars do not get modified until the very end, it's possible to get rid of the klugy var_equal and match_varid partial-matching routines, and just use plain equal() throughout the optimizer. This is a step towards allowing merge and hash joins to be done on expressions instead of only Vars ...
-
- 06 Aug, 1999 1 commit
-
-
Tom Lane authored
hashjoinable clause, not one path for a randomly-chosen element of each set of clauses with the same join operator. That is, if you wrote SELECT ... WHERE t1.f1 = t2.f2 and t1.f3 = t2.f4, and both '=' ops were the same opcode (say, all four fields are int4), then the system would either consider hashing on f1=f2 or on f3=f4, but it would *not* consider both possibilities. Boo hiss. Also, revise estimation of hashjoin costs to include a penalty when the inner join var has a high disbursion --- ie, the most common value is pretty common. This tends to lead to badly skewed hash bucket occupancy and way more comparisons than you'd expect on average. I imagine that the cost calculation still needs tweaking, but at least it generates a more reasonable plan than before on George Young's example.
-
- 16 Jul, 1999 1 commit
-
-
Bruce Momjian authored
-
- 15 Jul, 1999 1 commit
-
-
Bruce Momjian authored
-
- 07 Jul, 1999 3 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 25 May, 1999 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 01 May, 1999 1 commit
-
-
Tom Lane authored
the cost of reading the source data.
-
- 30 Apr, 1999 1 commit
-
-
Tom Lane authored
sometimes estimating an index scan of a table to be cheaper than a sequential scan of the same tuples...
-
- 05 Apr, 1999 1 commit
-
-
Tom Lane authored
2gig. Fix failure to reliably put the smaller relation on the inside of a hashjoin.
-