- 31 Jul, 2007 1 commit
-
-
Tom Lane authored
clauses in which one side or the other references both sides of the join cannot be removed as redundant, because that expression won't have been constrained below the join. Per report from Sergey Burladyan. CVS HEAD does not contain this bug due to EquivalenceClass rewrite, but it seems wise to include the regression test for it anyway.
-
- 22 May, 2007 1 commit
-
-
Tom Lane authored
in cases where a sub-SELECT inserts a WHERE clause between two outer joins, that clause may prevent us from re-ordering the two outer joins. The code was considering only the joins' own ON-conditions in determining reordering safety, which is not good enough. Add a "delay_upper_joins" flag to OuterJoinInfo to flag that we have detected such a clause and higher-level outer joins shouldn't be permitted to commute with this one. (This might seem overly coarse, but given the current rules for OJ reordering, it's sufficient AFAICT.) The failure case is actually pretty narrow: it needs a WHERE clause within the RHS of a left join that checks the RHS of a lower left join, but is not strict for that RHS (else we'd have simplified the lower join to a plain join). Even then no failure will be manifest unless the planner chooses to rearrange the join order. Per bug report from Adam Terrey.
-
- 16 Feb, 2007 1 commit
-
-
Tom Lane authored
considered when it is necessary to do so because of a join-order restriction (that is, an outer-join or IN-subselect construct). The former coding was a bit ad-hoc and inconsistent, and it missed some cases, as exposed by Mario Weilguni's recent bug report. His specific problem was that an IN could be turned into a "clauseless" join due to constant-propagation removing the IN's joinclause, and if the IN's subselect involved more than one relation and there was more than one such IN linking to the same upper relation, then the only valid join orders involve "bushy" plans but we would fail to consider the specific paths needed to get there. (See the example case added to the join regression test.) On examining the code I wonder if there weren't some other problem cases too; in particular it seems that GEQO was defending against a different set of corner cases than the main planner was. There was also an efficiency problem, in that when we did realize we needed a clauseless join because of an IN, we'd consider clauseless joins against every other relation whether this was sensible or not. It seems a better design is to use the outer-join and in-clause lists as a backup heuristic, just as the rule of joining only where there are joinclauses is a heuristic: we'll join two relations if they have a usable joinclause *or* this might be necessary to satisfy an outer-join or IN-clause join order restriction. I refactored the code to have just one place considering this instead of three, and made sure that it covered all the cases that any of them had been considering. Backpatch as far as 8.1 (which has only the IN-clause form of the disease). By rights 8.0 and 7.4 should have the bug too, but they accidentally fail to fail, because the joininfo structure used in those releases preserves some memory of there having once been a joinclause between the inner and outer sides of an IN, and so it leads the code in the right direction anyway. I'll be conservative and not touch them.
-
- 17 Mar, 2006 1 commit
-
-
Tom Lane authored
2005-05-13. When we find that a new inner tuple can't possibly match any outer tuple (because it contains a NULL), we can't immediately skip the tuple when we are in NEXTINNER state. Doing so can lead to emitting multiple copies of the tuple in FillInner mode, because we may rescan the tuple after returning to a previous marked tuple. Instead, proceed to NEXTOUTER state the same as we used to do. After we've found that there's no need to return to the marked position, we can go to SKIPINNER_ADVANCE state instead of SKIP_TEST when the inner tuple is unmatchable; this preserves the performance improvement. Per bug report from Bruce. I also made a couple of cosmetic code rearrangements and added a regression test for the problem.
-
- 14 Mar, 2006 1 commit
-
-
Tom Lane authored
during parse analysis, not only errors detected in the flex/bison stages. This is per my earlier proposal. This commit includes all the basic infrastructure, but locations are only tracked and reported for errors involving column references, function calls, and operators. More could be done later but this seems like a good set to start with. I've also moved the ReportSyntaxErrorPosition logic out of psql and into libpq, which should make it available to more people --- even within psql this is an improvement because warnings weren't handled by ReportSyntaxErrorPosition.
-
- 07 Mar, 2006 1 commit
-
-
Tom Lane authored
not likely ever to be implemented seeing it's been removed from SQL2003. This allows getting rid of the 'filter' version of yylex() that we had in parser.c, which should save at least a few microseconds in parsing.
-
- 22 Jul, 2005 1 commit
-
-
Tom Lane authored
coding would ignore startup cost differences of less than 1% of the estimated total cost; which was OK for normal planning but highly not OK if a very small LIMIT was applied afterwards, so that startup cost becomes the name of the game. Instead, compare startup and total costs fuzzily but independently. This changes the plan selected for two queries in the regression tests; adjust expected-output files for resulting changes in row order. Per reports from Dawid Kuroczko and Sam Mason.
-
- 07 Apr, 2005 1 commit
-
-
Neil Conway authored
in UPDATE. We also now issue a NOTICE if a query has _any_ implicit range table entries -- in the past, we would only warn about implicit RTEs in SELECTs with at least one explicit RTE. As a result of the warning change, 25 of the regression tests had to be updated. I also took the opportunity to remove some bogus whitespace differences between some of the float4 and float8 variants. I believe I have correctly updated all the platform-specific variants, but let me know if that's not the case. Original patch for DELETE ... USING from Euler Taveira de Oliveira, reworked by Neil Conway.
-
- 24 Mar, 2005 1 commit
-
-
Tom Lane authored
never-yet-vacuumed relation. This restores the pre-8.0 behavior of avoiding seqscans during initial data loading, while still allowing reasonable optimization after a table has been vacuumed. Several regression test cases revert to 7.4-like behavior, which is probably a good sign. Per gripes from Keith Browne and others.
-
- 03 Dec, 2004 1 commit
-
-
Tom Lane authored
better make sure the sort order is totally specified; else we get burnt by platform-specific behavior of qsort() with equal keys. Per buildfarm results.
-
- 02 Dec, 2004 1 commit
-
-
Tom Lane authored
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.
-
- 01 Dec, 2004 1 commit
-
-
Tom Lane authored
a relation's number of blocks, rather than the possibly-obsolete value in pg_class.relpages. Scale the value in pg_class.reltuples correspondingly to arrive at a hopefully more accurate number of rows. When pg_class contains 0/0, estimate a tuple width from the column datatypes and divide that into current file size to estimate number of rows. This improved methodology allows us to jettison the ancient hacks that put bogus default values into pg_class when a table is first created. Also, per a suggestion from Simon, make VACUUM (but not VACUUM FULL or ANALYZE) adjust the value it puts into pg_class.reltuples to try to represent the mean tuple density instead of the minimal density that actually prevails just after VACUUM. These changes alter the plans selected for certain regression tests, so update the expected files accordingly. (I removed join_1.out because it's not clear if it still applies; we can add back any variant versions as they are shown to be needed.)
-
- 25 Sep, 2003 1 commit
-
-
Peter Eisentraut authored
terms, add some clarifications, fix some untranslatable attempts at dynamic message building.
-
- 07 Aug, 2003 1 commit
-
-
Tom Lane authored
subplan it starts with, as they may be needed at upper join levels. See comments added to code for the non-obvious reason why. Per bug report from Robert Creager.
-
- 19 Jul, 2003 1 commit
-
-
Tom Lane authored
-
- 10 Feb, 2003 1 commit
-
-
Tom Lane authored
constraints appearing in outer-join qualification clauses are restricted as to when and where they can be pushed down. Add regression test to catch future errors in this area.
-
- 25 Jan, 2003 1 commit
-
-
Tom Lane authored
necessarily following the JOIN syntax to develop the query plan. The old behavior is still available by setting GUC variable JOIN_COLLAPSE_LIMIT to 1. Also create a GUC variable FROM_COLLAPSE_LIMIT to control the similar decision about when to collapse sub-SELECT lists into their parent lists. (This behavior existed already, but the limit was always GEQO_THRESHOLD/2; now it's separately adjustable.)
-
- 30 Oct, 2002 2 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
- 28 Oct, 2002 1 commit
-
-
Bruce Momjian authored
-
- 28 Apr, 2002 1 commit
-
-
Tom Lane authored
lists to join RTEs, attach a list of Vars and COALESCE expressions that will replace the join's alias variables during planning. This simplifies flatten_join_alias_vars while still making it easy to fix up varno references when transforming the query tree. Add regression test cases for interactions of subqueries with outer joins.
-
- 12 Mar, 2002 1 commit
-
-
Tom Lane authored
now has an RTE of its own, and references to its outputs now are Vars referencing the JOIN RTE, rather than CASE-expressions. This allows reverse-listing in ruleutils.c to use the correct alias easily, rather than painfully reverse-engineering the alias namespace as it used to do. Also, nested FULL JOINs work correctly, because the result of the inner joins are simple Vars that the planner can cope with. This fixes a bug reported a couple times now, notably by Tatsuo on 18-Nov-01. The alias Vars are expanded into COALESCE expressions where needed at the very end of planning, rather than during parsing. Also, beginnings of support for showing plan qualifier expressions in EXPLAIN. There are probably still cases that need work. initdb forced due to change of stored-rule representation.
-
- 14 Dec, 2000 1 commit
-
-
Tom Lane authored
comparison does not consider paths different when they differ only in uninteresting aspects of sort order. (We had a special case of this consideration for indexscans already, but generalize it to apply to ordered join paths too.) Be stricter about what is a canonical pathkey to allow faster pathkey comparison. Cache canonical pathkeys and dispersion stats for left and right sides of a RestrictInfo's clause, to avoid repeated computation. Total speedup will depend on number of tables in a query, but I see about 4x speedup of planning phase for a sample seven-table query.
-
- 06 Nov, 2000 2 commits
-
-
Tom Lane authored
to get platform-independent results.
-
Thomas G. Lockhart authored
Add more tests for JOIN syntax. All tests pass on my Linux box (except for the usual couple of lines for geometry).
-
- 12 Sep, 2000 1 commit
-
-
Tom Lane authored
ends to clean up (see my message of same date to pghackers), but mostly it works. INITDB REQUIRED!
-
- 12 May, 2000 1 commit
-
-
Tom Lane authored
Make it behave correctly when there are more than two tables being joined, also. Update regression test expected outputs.
-
- 15 Feb, 2000 1 commit
-
-
Thomas G. Lockhart authored
-
- 15 Jan, 2000 1 commit
-
-
Tom Lane authored
regress test expected outputs were committed with NOTICEs appearing out of order. Update to correct results.
-
- 09 Jan, 2000 1 commit
-
-
Tom Lane authored
which is broken in some weird way that I don't understand. I think it may be exposing a bug in the new psql --- for one thing, I get different results when I run psql by hand than the regress script gets. What the heck???
-
- 23 Feb, 1999 1 commit
-
-
Thomas G. Lockhart authored
-