11 Commits (8514bf45e755ed779d2076c4784d903777551b14)

Author	SHA1	Message	Date
Tom Lane	53e757689c	Make NestLoop plan nodes pass outer-relation variables into their inner ... relation using the general PARAM_EXEC executor parameter mechanism, rather than the ad-hoc kluge of passing the outer tuple down through ExecReScan. The previous method was hard to understand and could never be extended to handle parameters coming from multiple join levels. This patch doesn't change the set of possible plans nor have any significant performance effect, but it's necessary infrastructure for future generalization of the concept of an inner indexscan plan. ExecReScan's second parameter is now unused, so it's removed.	16 years ago
Bruce Momjian	0239800893	Update copyright for the year 2010.	16 years ago
Tom Lane	9f2ee8f287	Re-implement EvalPlanQual processing to improve its performance and eliminate ... a lot of strange behaviors that occurred in join cases. We now identify the "current" row for every joined relation in UPDATE, DELETE, and SELECT FOR UPDATE/SHARE queries. If an EvalPlanQual recheck is necessary, we jam the appropriate row into each scan node in the rechecking plan, forcing it to emit only that one row. The former behavior could rescan the whole of each joined relation for each recheck, which was terrible for performance, and what's much worse could result in duplicated output tuples. Also, the original implementation of EvalPlanQual could not re-use the recheck execution tree --- it had to go through a full executor init and shutdown for every row to be tested. To avoid this overhead, I've associated a special runtime Param with each LockRows or ModifyTable plan node, and arranged to make every scan node below such a node depend on that Param. Thus, by signaling a change in that Param, the EPQ machinery can just rescan the already-built test plan. This patch also adds a prohibition on set-returning functions in the targetlist of SELECT FOR UPDATE/SHARE. This is needed to avoid the duplicate-output-tuple problem. It seems fairly reasonable since the other restrictions on SELECT FOR UPDATE are meant to ensure that there is a unique correspondence between source tuples and result tuples, which an output SRF destroys as much as anything else does.	16 years ago
Tom Lane	421d7d8edb	Remove no-longer-needed ExecCountSlots infrastructure.	16 years ago
Bruce Momjian	d747140279	8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list ... provided by Andrew.	17 years ago
Tom Lane	25bf7f8b9b	Fix possible failures when a tuplestore switches from in-memory to on-disk ... mode while callers hold pointers to in-memory tuples. I reported this for the case of nodeWindowAgg's primary scan tuple, but inspection of the code shows that all of the calls in nodeWindowAgg and nodeCtescan are at risk. For the moment, fix it with a rather brute-force approach of copying whenever one of the at-risk callers requests a tuple. Later we might think of some sort of reference-count approach to reduce tuple copying.	17 years ago
Bruce Momjian	511db38ace	Update copyright for 2009.	17 years ago
Tom Lane	a80a12247a	Change WorkTableScan to not support backward scan. The apparent support ... didn't actually work, because nodeRecursiveunion.c creates the underlying tuplestore with backward scan disabled; which is a decision that we shouldn't reverse because of performance cost. We could imagine adding signaling from WorkTableScan to RecursiveUnion about whether backward scan is needed ... but in practice it'd be a waste of effort, because there simply isn't any current or plausible future scenario where WorkTableScan would be called on to scan backward. So just dike out the code that claims to support it.	17 years ago
Tom Lane	7028c13557	Fix an oversight in two different recent patches: nodes that support SRFs ... in their targetlists had better reset ps_TupFromTlist during ReScan calls. There's no need to back-patch here since nodeAgg and nodeGroup didn't even pretend to support SRFs in prior releases.	17 years ago
Tom Lane	0a7abcd4c9	Fix corner case wherein a WorkTableScan node could get initialized before the ... RecursiveUnion to which it refers. It turns out that we can just postpone the relevant initialization steps until the first exec call for the node, by which time the ancestor node must surely be initialized. Per report from Greg Stark.	17 years ago
Tom Lane	44d5be0e53	Implement SQL-standard WITH clauses, including WITH RECURSIVE. ... There are some unimplemented aspects: recursive queries must use UNION ALL (should allow UNION too), and we don't have SEARCH or CYCLE clauses. These might or might not get done for 8.4, but even without them it's a pretty useful feature. There are also a couple of small loose ends and definitional quibbles, which I'll send a memo about to pgsql-hackers shortly. But let's land the patch now so we can get on with other development. Yoshiyuki Asaba, with lots of help from Tatsuo Ishii and Tom Lane	17 years ago