- 06 1月, 2007 1 次提交
-
-
由 Bruce Momjian 提交于
back-stamped for this.
-
- 04 10月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 14 7月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 28 6月, 2006 1 次提交
-
-
由 Tom Lane 提交于
and batch files. Should reduce memory and I/O demands for such joins.
-
- 17 6月, 2006 1 次提交
-
-
由 Tom Lane 提交于
by creating a reference-count mechanism, similar to what we did a long time ago for catcache entries. The back branches have an ugly solution involving lots of extra copies, but this way is more efficient. Reference counting is only applied to tupdescs that are actually in caches --- there seems no need to use it for tupdescs that are generated in the executor, since they'll go away during plan shutdown by virtue of being in the per-query memory context. Neil Conway and Tom Lane
-
- 05 3月, 2006 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 28 2月, 2006 1 次提交
-
-
由 Tom Lane 提交于
bits indicating which optional capabilities can actually be exercised at runtime. This will allow Sort and Material nodes, and perhaps later other nodes, to avoid unnecessary overhead in common cases. This commit just adds the infrastructure and arranges to pass the correct flag values down to plan nodes; none of the actual optimizations are here yet. I'm committing this separately in case anyone wants to measure the added overhead. (It should be negligible.) Simon Riggs and Tom Lane
-
- 29 11月, 2005 2 次提交
-
-
由 Tom Lane 提交于
it's worth probing the outer relation for emptiness before building the hash table. To wit, if we're rescanning a join previously performed, remember whether we found it nonempty the previous time, and don't bother with the probe if it was nonempty. This buys back the performance lost in examples like Mario Weilguni's.
-
由 Tom Lane 提交于
one child or the other had a problem: they did not leave the node in a state that ExecReScanHashJoin would understand. In particular it would tend to fail to reset the child plans when needed. Per report from Mario Weilguni.
-
- 23 11月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
-
- 21 11月, 2005 1 次提交
-
-
由 Tom Lane 提交于
the convenience of tuptoaster.c and is no longer needed, so may as well get rid of some small amount of overhead.
-
- 18 10月, 2005 1 次提交
-
-
由 Tom Lane 提交于
by a recent HP C compiler. Mostly, get rid of useless local variables that are assigned to but never used.
-
- 15 10月, 2005 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 26 9月, 2005 1 次提交
-
-
由 Tom Lane 提交于
outer relation is empty did not work, per test case from Patrick Welche. It tried to use nodeHashjoin.c's high-level mechanisms for fetching an outer-relation tuple, but that code expected the hash table to be filled already. As patched, the code failed in corner cases such as having no outer-relation tuples for the first hash batch. Revert and rewrite.
-
- 15 6月, 2005 1 次提交
-
-
由 Neil Conway 提交于
work if either of the join relations are empty. The logic is: (1) if the inner relation's startup cost is less than the outer relation's startup cost and this is not an outer join, read a single tuple from the inner relation via ExecHash() - if NULL, we're done (2) read a single tuple from the outer relation - if NULL, we're done (3) build the hash table on the inner relation - if hash table is empty and this is not an outer join, we're done (4) otherwise, do hash join as usual The implementation uses the new MultiExecProcNode API, per a suggestion from Tom: invoking ExecHash() now produces the first tuple from the Hash node's child node, whereas MultiExecHash() builds the hash table. I had to put in a bit of a kludge to get the row count returned for EXPLAIN ANALYZE to be correct: since ExecHash() is invoked to return a tuple, and then MultiExecHash() is invoked, we would return one too many tuples to EXPLAIN ANALYZE. I hacked around this by just manually detecting this situation and subtracting 1 from the EXPLAIN ANALYZE row count.
-
- 17 4月, 2005 1 次提交
-
-
由 Tom Lane 提交于
return just a single tuple at a time. Currently the only such node type is Hash, but I expect we will soon have indexscans that can return tuple bitmaps. A side benefit is that EXPLAIN ANALYZE now shows the correct tuple count for a Hash node.
-
- 31 3月, 2005 1 次提交
-
-
由 Neil Conway 提交于
old comment in the code claimed that this was necessary. Since it is not actually necessary any more, it is clearer to remove the comment and just return NULL instead -- the return value of ExecHash() is not used.
-
- 17 3月, 2005 1 次提交
-
-
由 Tom Lane 提交于
of tuples when passing data up through multiple plan nodes. A slot can now hold either a normal "physical" HeapTuple, or a "virtual" tuple consisting of Datum/isnull arrays. Upper plan levels can usually just copy the Datum arrays, avoiding heap_formtuple() and possible subsequent nocachegetattr() calls to extract the data again. This work extends Atsushi Ogawa's earlier patch, which provided the key idea of adding Datum arrays to TupleTableSlots. (I believe however that something like this was foreseen way back in Berkeley days --- see the old comment on ExecProject.) A test case involving many levels of join of fairly wide tables (about 80 columns altogether) showed about 3x overall speedup, though simple queries will probably not be helped very much. I have also duplicated some code in heaptuple.c in order to provide versions of heap_formtuple and friends that use "bool" arrays to indicate null attributes, instead of the old convention of "char" arrays containing either 'n' or ' '. This provides a better match to the convention used by ExecEvalExpr. While I have not made a concerted effort to get rid of uses of the old routines, I think they should be deprecated and eventually removed.
-
- 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 ...
-
- 23 9月, 2004 1 次提交
-
-
由 Tom Lane 提交于
that the inner one is completely empty. Per recent discussion. Also some cosmetic cleanups in nearby code.
-
- 18 9月, 2004 1 次提交
-
-
由 Tom Lane 提交于
was large enough to be batched and the tuples fell into a batch where there were no inner tuples at all. Thanks to Xiaoyu Wang for finding a test case that exposed this long-standing bug.
-
- 29 8月, 2004 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 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.
-
- 08 1月, 2004 1 次提交
-
-
由 Neil Conway 提交于
pointer type when it is not necessary to do so. For future reference, casting NULL to a pointer type is only necessary when (a) invoking a function AND either (b) the function has no prototype OR (c) the function is a varargs function.
-
- 30 11月, 2003 1 次提交
-
-
由 PostgreSQL Daemon 提交于
$Header: -> $PostgreSQL Changes ...
-
- 26 11月, 2003 1 次提交
-
-
由 Tom Lane 提交于
the hashclauses field of the parent HashJoin. This avoids problems with duplicated links to SubPlans in hash clauses, as per report from Andrew Holm-Hansen.
-
- 25 9月, 2003 1 次提交
-
-
由 Peter Eisentraut 提交于
terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
-
- 09 8月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
-
- 04 8月, 2003 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 22 7月, 2003 1 次提交
-
-
由 Tom Lane 提交于
-
- 23 6月, 2003 1 次提交
-
-
由 Tom Lane 提交于
specific hash functions used by hash indexes, rather than the old not-datatype-aware ComputeHashFunc routine. This makes it safe to do hash joining on several datatypes that previously couldn't use hashing. The sets of datatypes that are hash indexable and hash joinable are now exactly the same, whereas before each had some that weren't in the other.
-
- 31 5月, 2003 1 次提交
-
-
由 Tom Lane 提交于
when the plan is ReScanned, we don't have to rebuild the hash table if there is no parameter change for its child node. This idea has been used for a long time in Sort and Material nodes, but was not in the hash code till now.
-
- 06 5月, 2003 1 次提交
-
-
由 Tom Lane 提交于
which does the same thing. Perhaps at one time there was a reason to allow plan nodes to store their result types in different places, but AFAICT that's been unnecessary for a good while.
-
- 28 3月, 2003 1 次提交
-
-
由 Bruce Momjian 提交于
(materialization into a tuple store) discussed on pgsql-hackers earlier. I've updated the documentation and the regression tests. Notes on the implementation: - I needed to change the tuple store API slightly -- it assumes that it won't be used to hold data across transaction boundaries, so the temp files that it uses for on-disk storage are automatically reclaimed at end-of-transaction. I added a flag to tuplestore_begin_heap() to control this behavior. Is changing the tuple store API in this fashion OK? - in order to store executor results in a tuple store, I added a new CommandDest. This works well for the most part, with one exception: the current DestFunction API doesn't provide enough information to allow the Executor to store results into an arbitrary tuple store (where the particular tuple store to use is chosen by the call site of ExecutorRun). To workaround this, I've temporarily hacked up a solution that works, but is not ideal: since the receiveTuple DestFunction is passed the portal name, we can use that to lookup the Portal data structure for the cursor and then use that to get at the tuple store the Portal is using. This unnecessarily ties the Portal code with the tupleReceiver code, but it works... The proper fix for this is probably to change the DestFunction API -- Tom suggested passing the full QueryDesc to the receiveTuple function. In that case, callers of ExecutorRun could "subclass" QueryDesc to add any additional fields that their particular CommandDest needed to get access to. This approach would work, but I'd like to think about it for a little bit longer before deciding which route to go. In the mean time, the code works fine, so I don't think a fix is urgent. - (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and adjusted the behavior of SCROLL in accordance with the discussion on -hackers. - (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml Neil Conway
-
- 28 1月, 2003 1 次提交
-
-
由 Tom Lane 提交于
Try to model the effect of rescanning input tuples in mergejoins; account for JOIN_IN short-circuiting where appropriate. Also, recognize that mergejoin and hashjoin clauses may now be more than single operator calls, so we have to charge appropriate execution costs.
-
- 21 1月, 2003 1 次提交
-
-
由 Tom Lane 提交于
There are two implementation techniques: the executor understands a new JOIN_IN jointype, which emits at most one matching row per left-hand row, or the result of the IN's sub-select can be fed through a DISTINCT filter and then joined as an ordinary relation. Along the way, some minor code cleanup in the optimizer; notably, break out most of the jointree-rearrangement preprocessing in planner.c and put it in a new file prep/prepjointree.c.
-