- 28 8月, 2005 1 次提交
-
-
由 Tom Lane 提交于
are cases where it appears to have zero run cost.
-
- 06 6月, 2005 1 次提交
-
-
由 Tom Lane 提交于
a new PlannerInfo struct, which is passed around instead of the bare Query in all the planning code. This commit is essentially just a code-beautification exercise, but it does open the door to making larger changes to the planner data structures without having to muck with the widely-known Query struct.
-
- 23 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
but the code is basically working. Along the way, rewrite the entire approach to processing OR index conditions, and make it work in join cases for the first time ever. orindxpath.c is now basically obsolete, but I left it in for the time being to allow easy comparison testing against the old implementation.
-
- 22 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
logic operations during planning. Seems cleaner to create two new Path node types, instead --- this avoids duplication of cost-estimation code. Also, create an enable_bitmapscan GUC parameter to control use of bitmap plans.
-
- 21 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
-
- 20 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
scans, using in-memory tuple ID bitmaps as the intermediary. The planner frontend (path creation and cost estimation) is not there yet, so none of this code can be executed. I have tested it using some hacked planner code that is far too ugly to see the light of day, however. Committing now so that the bulk of the infrastructure changes go in before the tree drifts under me.
-
- 04 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
outer side of an outer join. Per andrew@supernews.
-
- 28 3月, 2005 1 次提交
-
-
由 Tom Lane 提交于
access: define new index access method functions 'amgetmulti' that can fetch multiple TIDs per call. (The functions exist but are totally untested as yet.) Since I was modifying pg_am anyway, remove the no-longer-needed 'rel' parameter from amcostestimate functions, and also remove the vestigial amowner column that was creating useless work for Alvaro's shared-object-dependencies project. Initdb forced due to changes in pg_am.
-
- 27 3月, 2005 1 次提交
-
-
由 Tom Lane 提交于
structs. There are many places in the planner where we were passing both a rel and an index to subroutines, and now need only pass the index struct. Notationally simpler, and perhaps a tad faster.
-
- 07 3月, 2005 1 次提交
-
-
由 Tom Lane 提交于
on-the-fly, and thereby avoid blowing out memory when the planner has underestimated the hash table size. Hash join will now obey the work_mem limit with some faithfulness. Per my recent proposal (hash aggregate part isn't done yet though).
-
- 01 1月, 2005 1 次提交
-
-
由 PostgreSQL Daemon 提交于
Tag appropriate files for rc3 Also performed an initial run through of upgrading our Copyright date to extend to 2005 ... first run here was very simple ... change everything where: grep 1996-2004 && the word 'Copyright' ... scanned through the generated list with 'less' first, and after, to make sure that I only picked up the right entries ...
-
- 02 12月, 2004 1 次提交
-
-
由 Tom Lane 提交于
In particular, there was a mathematical tie between the two possible nestloop-with-materialized-inner-scan plans for a join (ie, we computed the same cost with either input on the inside), resulting in a roundoff error driven choice, if the relations were both small enough to fit in sort_mem. Add a small cost factor to ensure we prefer materializing the smaller input. This changes several regression test plans, but with any luck we will now have more stability across platforms.
-
- 23 10月, 2004 1 次提交
-
-
由 Tom Lane 提交于
-
- 29 8月, 2004 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 05 8月, 2004 1 次提交
-
-
由 Tom Lane 提交于
and documentation to reference 8.0 instead of 7.5.
-
- 11 6月, 2004 1 次提交
-
-
由 Tom Lane 提交于
when random_page_cost has a small value. Per Manfred Koizar, though I didn't use his equation exactly.
-
- 05 6月, 2004 1 次提交
-
-
由 Tom Lane 提交于
1. Solve the problem of not having TOAST references hiding inside composite values by establishing the rule that toasting only goes one level deep: a tuple can contain toasted fields, but a composite-type datum that is to be inserted into a tuple cannot. Enforcing this in heap_formtuple is relatively cheap and it avoids a large increase in the cost of running the tuptoaster during final storage of a row. 2. Fix some interesting problems in expansion of inherited queries that reference whole-row variables. We never really did this correctly before, but it's now relatively painless to solve by expanding the parent's whole-row Var into a RowExpr() selecting the proper columns from the child. If you dike out the preventive check in CheckAttributeType(), composite-type columns now seem to actually work. However, we surely cannot ship them like this --- without I/O for composite types, you can't get pg_dump to dump tables containing them. So a little more work still to do.
-
- 01 6月, 2004 1 次提交
-
-
由 Tom Lane 提交于
being a plain List.
-
- 31 5月, 2004 1 次提交
-
-
由 Neil Conway 提交于
list compatibility API by default. While doing this, I decided to keep the llast() macro around and introduce llast_int() and llast_oid() variants.
-
- 26 5月, 2004 1 次提交
-
-
由 Neil Conway 提交于
In the past, we used a 'Lispy' linked list implementation: a "list" was merely a pointer to the head node of the list. The problem with that design is that it makes lappend() and length() linear time. This patch fixes that problem (and others) by maintaining a count of the list length and a pointer to the tail node along with each head node pointer. A "list" is now a pointer to a structure containing some meta-data about the list; the head and tail pointers in that structure refer to ListCell structures that maintain the actual linked list of nodes. The function names of the list API have also been changed to, I hope, be more logically consistent. By default, the old function names are still available; they will be disabled-by-default once the rest of the tree has been updated to use the new API names.
-
- 07 4月, 2004 1 次提交
-
-
由 Tom Lane 提交于
That particular corner case is not exactly compelling, but given 7.4's ability to discard redundant join clauses, it is possible for the situation to arise from queries that are not so obviously silly. Per bug report of 6-Apr-04.
-
- 17 2月, 2004 1 次提交
-
-
由 Tom Lane 提交于
corner cases that could stand improvement, but it does all the basic stuff. A byproduct is that the selectivity routines are no longer constrained to working on simple Vars; we might in future be able to improve the behavior for subexpressions that don't match indexes.
-
- 04 2月, 2004 1 次提交
-
-
由 Tom Lane 提交于
Make btree index creation and initial validation of foreign-key constraints use maintenance_work_mem rather than work_mem as their memory limit. Add some code to guc.c to allow these variables to be referenced by their old names in SHOW and SET commands, for backwards compatibility.
-
- 19 1月, 2004 1 次提交
-
-
由 Tom Lane 提交于
we have detected that an IN subquery must return unique results.
-
- 06 1月, 2004 2 次提交
-
-
由 Tom Lane 提交于
regular qpqual ('filter condition'), add special-purpose code to nodeIndexscan.c to recheck them. This ends being almost no net addition of code, because the removal of planner code balances out the extra executor code, but it is significantly more efficient when a lossy operator is involved in an OR indexscan. The old implementation had to recheck the entire indexqual in such cases.
-
由 Tom Lane 提交于
with index qual clauses in the Path representation. This saves a little work during createplan and (probably more importantly) allows reuse of cached selectivity estimates during indexscan planning. Also fix latent bug: wrong plan would have been generated for a 'special operator' used in a nestloop-inner-indexscan join qual, because the special operator would not have gotten into the list of quals to recheck. This bug is only latent because at present the special-operator code could never trigger on a join qual, but sooner or later someone will want to do it.
-
- 05 1月, 2004 1 次提交
-
-
由 Tom Lane 提交于
join conditions in which each OR subclause includes a constraint on the same relation. This implements the other useful side-effect of conversion to CNF format, without its unpleasant side-effects. As per pghackers discussion of a few weeks ago.
-
- 04 1月, 2004 1 次提交
-
-
由 Tom Lane 提交于
teaching the latter to accept either RestrictInfo nodes or bare clause expressions; and cache the selectivity result in the RestrictInfo node when possible. This extends the caching behavior of approx_selectivity to many more contexts, and should reduce duplicate selectivity calculations.
-
- 18 12月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
```------------------------------------------------------------------- /* * relation_byte_size * Estimate the storage space in bytes for a given number of tuples * of a given width (size in bytes). */ static double relation_byte_size(double tuples, int width) { return tuples * (MAXALIGN(width) + MAXALIGN(sizeof(HeapTupleData))); } ``` ------------------------------------------------------------------- Shouldn't this be HeapTupleHeaderData and not HeapTupleData ? (Of course, from a costing perspective these shouldn't be very different but ...) Sailesh Krishnamurthy
-
- 04 12月, 2003 1 次提交
-
-
由 Tom Lane 提交于
and hash bucket-size estimation. Issue has been there awhile but is more critical in 7.4 because it affects varchar columns. Per report from Greg Stark.
-
- 30 11月, 2003 1 次提交
-
-
由 PostgreSQL Daemon 提交于
$Header: -> $PostgreSQL Changes ...
-
- 06 10月, 2003 1 次提交
-
-
由 Tom Lane 提交于
statistics, but there is a unique index on the column, we can safely assume it's well-distributed.
-
- 09 8月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 04 8月, 2003 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 25 7月, 2003 1 次提交
-
-
由 Tom Lane 提交于
-
- 15 7月, 2003 1 次提交
-
-
由 Tom Lane 提交于
for each row processed, and don't forget the evaluation cost of any restriction clauses attached to the node. Per discussion with Greg Stark.
-
- 30 6月, 2003 1 次提交
-
-
由 Tom Lane 提交于
node emits only those vars that are actually needed above it in the plan tree. (There were comments in the code suggesting that this was done at some point in the dim past, but for a long time we have just made join nodes emit everything that either input emitted.) Aside from being marginally more efficient, this fixes the problem noted by Peter Eisentraut where a join above an IN-implemented-as-join might fail, because the subplan targetlist constructed in the latter case didn't meet the expectation of including everything. Along the way, fix some places that were O(N^2) in the targetlist length. This is not all the trouble spots for wide queries by any means, but it's a step forward.
-
- 29 6月, 2003 1 次提交
-
-
由 Tom Lane 提交于
'scalar op ALL (array)', where the operator is applied between the lefthand scalar and each element of the array. The operator must yield boolean; the result of the construct is the OR or AND of the per-element results, respectively. Original coding by Joe Conway, after an idea of Peter's. Rewritten by Tom to keep the implementation strictly separate from subqueries.
-