- 14 3月, 2019 1 次提交
-
-
由 Daniel Gustafsson 提交于
As we merge with upstream and by that keep refining the Postgres planner, legacy planner is no longer a suitable name. This changes all variations of the spelling (legacy planner, legacy optimizer, legacy query optimizer etc) to say "Postgres" rather than "legacy". Reviewed-by: NVenkatesh Raghavan <vraghavan@pivotal.io> Reviewed-by: NDavid Yozie <dyozie@pivotal.io> Reviewed-by: NGeorgios Kokolatos <gkokolatos@pivotal.io>
-
- 15 2月, 2019 1 次提交
-
-
由 Jesse Zhang 提交于
This reverts the following commits: commit 0ee987e64 - "Don't dispatch index creations too eagerly in ALTER TABLE." commit 28dd0152 - "Enable alter table column with index (#6286)" The motivation of commit 0ee987e64 is to stop eager dispatch of index creation during ALTER TABLE, and instead perform a single dispatch. Doing so prevents index name already exists errors when altering data types on indexed columns such as: ALTER TABLE foo ALTER COLUMN test TYPE integer; ERROR: relation "foo_test_key" already exists Unfortunately, without eager dispatch of index creation the QEs can choose a different name for a relation than was chosen on the QD. Eager dispatch was the only mechanism we had to ensure a deterministic and consistent index name between the QE and QD in some scenarios. In the absence of another mechanism we must revert this commit. This commit also rolls back commit 28dd0125 to enable altering data types on indexed columns, which required commit 0ee987e64. Co-authored-by: NKalen Krempely <kkrempely@pivotal.io> Co-authored-by: NTaylor Vesely <tvesely@pivotal.io> Co-authored-by: NDavid Krieger <dkrieger@pivotal.io>
-
- 13 2月, 2019 1 次提交
-
-
由 David Kimura 提交于
Currently exlusion constraints do not work correctly in MPP environment. For example, if the exclusion constraint is on a column which is not the table's distribution key, then it is possible to get wrong results. Following statements should give 1 row because first tuple should exclude the second. ``` CREATE TABLE t(a int, b int, EXCLUDE (b WITH =)) DISTIBUTED BY (a); INSERT INTO t values (1, 1), (2, 1); ``` However, that is not currently the case if the distribution key hashes to different segments. This commit removes exclusion constraints feature entirely until there is a way to coordinate exclusion constriants between the segments. Co-authored-by: NAdam Berlin <aberlin@pivotal.io> Co-authored-by: NMelanie Plageman <melanieplageman@gmail.com> Co-authored-by: NDavid Kimura <dkimura@pivotal.io>
-
- 29 12月, 2018 1 次提交
-
-
由 Heikki Linnakangas 提交于
We used to call some node types different names in EXPLAIN output, depending on whether the plan was generated by ORCA or the Postgres planner. Also, a Bitmap Heap Scan used to be called differently, when the table was an AO or AOCS table, but only in planner-generated plans. There was some historical justification for this, because they used to be different executor node types, but commit db516347 removed last such differences. Full list of renames: Table Scan -> Seq Scan Append-only Scan -> Seq Scan Append-only Columnar Scan -> Seq Scan Dynamic Table Scan -> Dynamic Seq Scan Bitmap Table Scan -> Bitmap Heap Scan Bitmap Append-Only Row-Oriented Scan -> Bitmap Heap Scan Bitmap Append-Only Column-Oriented Scan -> Bitmap Heap Scan Dynamic Bitmap Table Scan -> Dynamic Bitmap Heap Scan
-
- 05 12月, 2018 1 次提交
-
-
由 Heikki Linnakangas 提交于
As the comments in code explain, the simple union all pullup optimization is problematic in GPDB. I don't think we have plans to "fix" it any time soon.
-
- 22 9月, 2018 1 次提交
-
-
由 Heikki Linnakangas 提交于
We had changed this in GPDB, to print less parens. That's fine and dandy, but it hardly seems worth it to carry a diff vs upstream for this. Which format is better, is a matter of taste. The extra parens make some expressions more clear, but OTOH, it's unnecessarily verbose for simple expressions. Let's follow the upstream on this. These changes were made to GPDB back in 2006, as part of backporting to EXPLAIN-related patches from PostgreSQL 8.2. But I didn't see any explanation for this particular change in output in that commit message. It's nice to match upstream, to make merging easier. However, this won't make much difference to that: almost all EXPLAIN plans in regression tests are different from upstream anyway, because GPDB needs Motion nodes for most queries. But every little helps.
-
- 21 9月, 2018 1 次提交
-
-
由 Heikki Linnakangas 提交于
When creating an ORCA plan for "INSERT ... (<col list>) VALUES (<values>)" statement, the ORCA translator performed NULL checks for any columns not listed in the column list. Nothing wrong with that per se, but we needed to keep the error messages in sync, or we'd get regression test failures caused by different messages. To simplify that, remove the check from ORCA translator, and rely on the execution time check. We bumped into this while working on the 9.3 merge, because 9.3 added DETAIL to the error message in executor: postgres=# create table notnulls (a text NOT NULL, b text NOT NULL); CREATE TABLE postgres=# insert into notnulls (a) values ('x'); ERROR: null value in column "b" violates not-null constraint postgres=# insert into notnulls (a,b) values ('x', NULL); ERROR: null value in column "b" violates not-null constraint (seg2 127.0.0.1:40002 pid=26547) DETAIL: Failing row contains (x, null). Doing this now will avoid that inconsistency in the merge. One little difference with this is that EXPLAIN on an insert like above now works, and you only get the error when you try to execute it. Before, with ORCA, even EXPLAIN would throw the error.
-
- 03 8月, 2018 1 次提交
-
-
由 Karen Huddleston 提交于
This reverts commit 4750e1b6.
-
- 02 8月, 2018 1 次提交
-
-
由 Richard Guo 提交于
This is the final batch of commits from PostgreSQL 9.2 development, up to the point where the REL9_2_STABLE branch was created, and 9.3 development started on the PostgreSQL master branch. Notable upstream changes: * Index-only scan was included in the batch of upstream commits. It allows queries to retrieve data only from indexes, avoiding heap access. * Group commit was added to work effectively under heavy load. Previously, batching of commits became ineffective as the write workload increased, because of internal lock contention. * A new fast-path lock mechanism was added to reduce the overhead of taking and releasing certain types of locks which are taken and released very frequently but rarely conflict. * The new "parameterized path" mechanism was added. It allows inner index scans to use values from relations that are more than one join level up from the scan. This can greatly improve performance in situations where semantic restrictions (such as outer joins) limit the allowed join orderings. * SP-GiST (Space-Partitioned GiST) index access method was added to support unbalanced partitioned search structures. For suitable problems, SP-GiST can be faster than GiST in both index build time and search time. * Checkpoints now are performed by a dedicated background process. Formerly the background writer did both dirty-page writing and checkpointing. Separating this into two processes allows each goal to be accomplished more predictably. * Custom plan was supported for specific parameter values even when using prepared statements. * API for FDW was improved to provide multiple access "paths" for their tables, allowing more flexibility in join planning. * Security_barrier option was added for views to prevents optimizations that might allow view-protected data to be exposed to users. * Range data type was added to store a lower and upper bound belonging to its base data type. * CTAS (CREATE TABLE AS/SELECT INTO) is now treated as utility statement. The SELECT query is planned during the execution of the utility. To conform to this change, GPDB executes the utility statement only on QD and dispatches the plan of the SELECT query to QEs. Co-authored-by: NAdam Lee <ali@pivotal.io> Co-authored-by: NAlexandra Wang <lewang@pivotal.io> Co-authored-by: NAshwin Agrawal <aagrawal@pivotal.io> Co-authored-by: NAsim R P <apraveen@pivotal.io> Co-authored-by: NDaniel Gustafsson <dgustafsson@pivotal.io> Co-authored-by: NGang Xiong <gxiong@pivotal.io> Co-authored-by: NHaozhou Wang <hawang@pivotal.io> Co-authored-by: NHeikki Linnakangas <hlinnakangas@pivotal.io> Co-authored-by: NJesse Zhang <sbjesse@gmail.com> Co-authored-by: NJinbao Chen <jinchen@pivotal.io> Co-authored-by: NJoao Pereira <jdealmeidapereira@pivotal.io> Co-authored-by: NMelanie Plageman <mplageman@pivotal.io> Co-authored-by: NPaul Guo <paulguo@gmail.com> Co-authored-by: NRichard Guo <guofenglinux@gmail.com> Co-authored-by: NShujie Zhang <shzhang@pivotal.io> Co-authored-by: NTaylor Vesely <tvesely@pivotal.io> Co-authored-by: NZhenghua Lyu <zlv@pivotal.io>
-
- 12 3月, 2018 1 次提交
-
-
由 Tom Lane 提交于
One of the things canonicalize_qual() does is to remove constant-NULL subexpressions of top-level AND/OR clauses. It does that on the assumption that what it's given is a top-level WHERE clause, so that NULL can be treated like FALSE. Although this is documented down inside a subroutine of canonicalize_qual(), it wasn't mentioned in the documentation of that function itself, and some callers hadn't gotten that memo. Notably, commit d007a950 caused get_relation_constraints() to apply canonicalize_qual() to CHECK constraints. That allowed constraint exclusion to misoptimize situations in which a CHECK constraint had a provably-NULL subclause, as seen in the regression test case added here, in which a child table that should be scanned is not. (Although this thinko is ancient, the test case doesn't fail before 9.2, for reasons I've not bothered to track down in detail. There may be related cases that do fail before that.) More recently, commit f0e44751 added an independent bug by applying canonicalize_qual() to index expressions, which is even sillier since those might not even be boolean. If they are, though, I think this could lead to making incorrect index entries for affected index expressions in v10. I haven't attempted to prove that though. To fix, add an "is_check" parameter to canonicalize_qual() to specify whether it should assume WHERE or CHECK semantics, and make it perform NULL-elimination accordingly. Adjust the callers to apply the right semantics, or remove the call entirely in cases where it's not known that the expression has one or the other semantics. I also removed the call in some cases involving partition expressions, where it should be a no-op because such expressions should be canonical already ... and was a no-op, independently of whether it could in principle have done something, because it was being handed the qual in implicit-AND format which isn't what it expects. In HEAD, add an Assert to catch that type of mistake in future. This represents an API break for external callers of canonicalize_qual(). While that's intentional in HEAD to make such callers think about which case applies to them, it seems like something we probably wouldn't be thanked for in released branches. Hence, in released branches, the extra parameter is added to a new function canonicalize_qual_ext(), and canonicalize_qual() is a wrapper that retains its old behavior. Patch by me with suggestions from Dean Rasheed. Back-patch to all supported branches. Discussion: https://postgr.es/m/24475.1520635069@sss.pgh.pa.us
-
- 21 11月, 2017 1 次提交
-
-
由 Heikki Linnakangas 提交于
These were added in GPDB a long time ago, probably before gpdiff.pl was introduced to mask row order differences in regression test output. But now that gpdiff.pl can do that, these are unnecessary. Revert to match the upstream more closely. This includes updates to the 'rules' and 'inherit' tests, although they are disabled and still doesn't pass after these changes.
-
- 05 1月, 2017 1 次提交
-
-
由 Tom Lane 提交于
Inheritance operations must treat the OID column, if any, much like regular user columns. But MergeAttributesIntoExisting() neglected to do that, leading to weird results after a table with OIDs is associated to a parent with OIDs via ALTER TABLE ... INHERIT. Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some adjustments by me. It's been broken all along, so back-patch to all supported branches. Discussion: https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28298@lab.ntt.co.jp
-
- 14 10月, 2016 1 次提交
-
-
由 Tom Lane 提交于
It's not good for an inherited child constraint to be marked connoinherit; that would result in the constraint not propagating to grandchild tables, if any are created later. The code mostly prevented this from happening but there was one case that was missed. This is somewhat related to commit e55a946a, which also tightened checks on constraint merging. Hence, back-patch to 9.2 like that one. This isn't so much because there's a concrete feature-related reason to stop there, as to avoid having more distinct behaviors than we have to in this area. Amit Langote Discussion: <b28ee774-7009-313d-dd55-5bdd81242c41@lab.ntt.co.jp>
-
- 09 10月, 2016 1 次提交
-
-
由 Tom Lane 提交于
Historically, we've allowed users to add a CHECK constraint to a child table and then add an identical CHECK constraint to the parent. This results in "merging" the two constraints so that the pre-existing child constraint ends up with both conislocal = true and coninhcount > 0. However, if you tried to do it in the other order, you got a duplicate constraint error. This is problematic for pg_dump, which needs to issue separated ADD CONSTRAINT commands in some cases, but has no good way to ensure that the constraints will be added in the required order. And it's more than a bit arbitrary, too. The goal of complaining about duplicated ADD CONSTRAINT commands can be served if we reject the case of adding a constraint when the existing one already has conislocal = true; but if it has conislocal = false, let's just make the ADD CONSTRAINT set conislocal = true. In this way, either order of adding the constraints has the same end result. Another problem was that the code allowed creation of a parent constraint marked convalidated that is merged with a child constraint that is !convalidated. In this case, an inheritance scan of the parent table could emit some rows violating the constraint condition, which would be an unexpected result given the marking of the parent constraint as validated. Hence, forbid merging of constraints in this case. (Note: valid child and not-valid parent seems fine, so continue to allow that.) Per report from Benedikt Grundmann. Back-patch to 9.2 where we introduced possibly-not-valid check constraints. The second bug obviously doesn't apply before that, and I think the first doesn't either, because pg_dump only gets into this situation when dealing with not-valid constraints. Report: <CADbMkNPT-Jz5PRSQ4RbUASYAjocV_KHUWapR%2Bg8fNvhUAyRpxA%40mail.gmail.com> Discussion: <22108.1475874586@sss.pgh.pa.us>
-
- 15 4月, 2016 1 次提交
-
-
由 Jimmy Yih 提交于
Currently, the error reporting for duplicate key value violation for unique indexes does not contain useful information for users when debugging. This commit backports two commits from PostgreSQL (shown below) and updates our multikey tuplesort to use the same. Now the error will display the first instance of a duplicate key violation. Authors: Jimmy Yih and Abhijit Subramanya commit b680ae4b Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Sat Aug 1 19:59:41 2009 +0000 Improve unique-constraint-violation error messages to include the exact values being complained of. In passing, also remove the arbitrary length limitation in the similar error detail message for foreign key violations. Itagaki Takahiro Conflicts: contrib/citext/expected/citext.out contrib/citext/expected/citext_1.out src/backend/access/common/indextuple.c src/backend/access/index/genam.c src/backend/access/nbtree/nbtinsert.c src/backend/utils/adt/ri_triggers.c src/backend/utils/adt/ruleutils.c src/include/access/genam.h src/include/access/itup.h src/include/utils/builtins.h src/test/regress/expected/alter_table.out src/test/regress/expected/arrays.out src/test/regress/expected/create_index.out src/test/regress/expected/plpgsql.out src/test/regress/expected/transactions.out src/test/regress/expected/uuid.out src/test/regress/output/constraints.source src/test/regress/output/tablespace.source commit 527f0ae3 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Sat Aug 1 20:59:17 2009 +0000 Department of second thoughts: let's show the exact key during unique index build failures, too. Refactor a bit more since that error message isn't spelled the same. Conflicts: src/backend/access/nbtree/nbtinsert.c src/backend/utils/sort/tuplesort.c src/test/regress/expected/alter_table.out src/test/regress/expected/create_index.out
-
- 28 10月, 2015 1 次提交
-
-
- 07 8月, 2015 1 次提交
-
-
由 Tom Lane 提交于
Formerly, this function would always return "true" for an appendrel child relation, because it would think that the appendrel parent was a potential join target for the child. In principle that should only lead to some inefficiency in planning, but fuzz testing by Andreas Seltenreich disclosed that it could lead to "could not find pathkey item to sort" planner errors in odd corner cases. Specifically, we would think that all columns of a child table's multicolumn index were interesting pathkeys, causing us to generate a MergeAppend path that sorts by all the columns. However, if any of those columns weren't actually used above the level of the appendrel, they would not get added to that rel's targetlist, which would result in being unable to resolve the MergeAppend's sort keys against its targetlist during createplan.c. Backpatch to 9.3. In older versions, columns of an appendrel get added to its targetlist even if they're not mentioned above the scan level, so that the failure doesn't occur. It might be worth back-patching this fix to older versions anyway, but I'll refrain for the moment.
-
- 16 4月, 2014 1 次提交
-
-
由 Bruce Momjian 提交于
In psql \d+, display oids only when they exist, and display replication identity only when it is non-default. Also document the defaults for replication identity for system and non-system tables. Update regression output.
-
- 30 3月, 2014 1 次提交
-
-
由 Bruce Momjian 提交于
INDEX is already displayed on the index, and we now exclude pg_catalog. DEFAULT is not displayed.
-
- 26 3月, 2014 1 次提交
-
-
由 Bruce Momjian 提交于
Display "replica identity" only for \d plus mode, exclude system schema objects, and display all possible values, not just non-default, non-index ones.
-
- 15 12月, 2013 1 次提交
-
-
由 Tom Lane 提交于
Fix an oversight in commit b3aaf908: we do indeed need to process the planner's append_rel_list when copying RTE subqueries, because if any of them were flattenable UNION ALL subqueries, the append_rel_list shows which subquery RTEs were pulled up out of which other ones. Without this, UNION ALL subqueries aren't correctly inserted into the update plans for inheritance child tables after the first one, typically resulting in no update happening for those child table(s). Per report from Victor Yegorov. Experimentation with this case also exposed a fault in commit a7b96538: if an inherited UPDATE/DELETE was proven totally dummy by constraint exclusion, we might arrive at add_rtes_to_flat_rtable with root->simple_rel_array being NULL. This should be interpreted as not having any RelOptInfos. I chose to code the guard as a check against simple_rel_array_size, so as to also provide some protection against indexing off the end of the array. Back-patch to 9.2 where the faulty code was added.
-
- 08 11月, 2013 1 次提交
-
-
由 Tom Lane 提交于
Before jamming a desired targetlist into a plan node, one really ought to make sure the plan node can handle projections, and insert a buffering Result plan node if not. planagg.c forgot to do this, which is a hangover from the days when it only dealt with IndexScan plan types. MergeAppend doesn't project though, not to mention that it gets unhappy if you remove its possibly-resjunk sort columns. The code accidentally failed to fail for cases in which the min/max argument was a simple Var, because the new targetlist would be equivalent to the original "flat" tlist anyway. For any more complex case, it's been broken since 9.1 where we introduced the ability to optimize min/max using MergeAppend, as reported by Raphael Bauduin. Fix by duplicating the logic from grouping_planner that decides whether we need a Result node. In 9.2 and 9.1, this requires back-porting the tlist_same_exprs() function introduced in commit 4387cf95, else we'd uselessly add a Result node in cases that worked before. It's rather tempting to back-patch that whole commit so that we can avoid extra Result nodes in mainline cases too; but I'll refrain, since that code hasn't really seen all that much field testing yet.
-
- 31 8月, 2013 2 次提交
- 15 3月, 2013 1 次提交
-
-
由 Tom Lane 提交于
The planner sometimes inserts Result nodes to perform column projections (ie, arbitrary scalar calculations) above plan nodes that lack projection logic of their own. However, we did that even if the lower plan node was in fact producing the required column set already; which is a pretty common case given the popularity of "SELECT * FROM ...". Measurements show that the useless plan node adds non-negligible overhead, especially when there are many columns in the result. So add a check to avoid inserting a Result node unless there's something useful for it to do. There are a couple of remaining places where unnecessary Result nodes could get inserted, but they are (a) much less performance-critical, and (b) coded in such a way that it's hard to avoid inserting a Result, because the desired tlist is changed on-the-fly in subsequent logic. We'll leave those alone for now. Kyotaro Horiguchi; reviewed and further hacked on by Amit Kapila and Tom Lane.
-
- 22 9月, 2012 1 次提交
-
-
由 Tom Lane 提交于
The previous scheme had bugs in some corner cases involving tables that had been renamed since a view was made. This could result in dumped views that failed to reload or reloaded incorrectly, as seen in bug #7553 from Lloyd Albin, as well as in some pgsql-hackers discussion back in January. Also, its behavior for printing EXPLAIN plans was sometimes confusing because of willingness to use the same alias for multiple RTEs (it was Ashutosh Bapat's complaint about that aspect that started the January thread). To fix, ensure that each RTE in the query has a unique unqualified alias, by modifying the alias if necessary (we add "_" and digits as needed to create a non-conflicting name). Then we can just print its variables with that alias, avoiding the confusing and bug-prone scheme of sometimes schema-qualifying variable names. In EXPLAIN, it proves to be expedient to take the further step of only assigning such aliases to RTEs that are actually referenced in the query, since the planner has a habit of generating extra RTEs with the same alias in situations such as inheritance-tree expansion. Although this fixes a bug of very long standing, I'm hesitant to back-patch such a noticeable behavioral change. My experiments while creating a regression test convinced me that actually incorrect output (as opposed to confusing output) occurs only in very narrow cases, which is backed up by the lack of previous complaints from the field. So we may be better off living with it in released branches; and in any case it'd be smart to let this ripen awhile in HEAD before we consider back-patching it.
-
- 25 7月, 2012 1 次提交
-
-
由 Alvaro Herrera 提交于
The initially implemented syntax, "CHECK NO INHERIT (expr)" was not deemed very good, so switch to "CHECK (expr) NO INHERIT" instead. This way it looks similar to SQL-standards compliant constraint attribute. Backport to 9.2 where the new syntax and feature was introduced. Per discussion.
-
- 22 7月, 2012 1 次提交
- 21 7月, 2012 1 次提交
-
-
由 Alvaro Herrera 提交于
The code was setting it true for other constraints, which is bogus. Doing so caused bogus catalog entries for such constraints, and in particular caused an error to be raised when trying to drop a constraint of types other than CHECK from a table that has children, such as reported in bug #6712. In 9.2, additionally ignore connoinherit=true for other constraint types, to avoid having to force initdb; existing databases might already contain bogus catalog entries. Includes a catversion bump (in HEAD only). Bug report from Miroslav Šulc Analysis from Amit Kapila and Noah Misch; Amit also contributed the patch.
-
- 05 7月, 2012 1 次提交
-
-
由 Robert Haas 提交于
Per recent discussion on pgsql-hackers, these messages are too chatty for most users.
-
- 21 4月, 2012 1 次提交
-
-
由 Alvaro Herrera 提交于
The original syntax wasn't universally loved, and it didn't allow its usage in CREATE TABLE, only ALTER TABLE. It now works everywhere, and it also allows using ALTER TABLE ONLY to add an uninherited CHECK constraint, per discussion. The pg_constraint column has accordingly been renamed connoinherit. This commit partly reverts some of the changes in 61d81bd2, particularly some pg_dump and psql bits, because now pg_get_constraintdef includes the necessary NO INHERIT within the constraint definition. Author: Nikhil Sontakke Some tweaks by me
-
- 20 4月, 2012 1 次提交
-
-
由 Tom Lane 提交于
This patch adjusts the treatment of parameterized paths so that all paths with the same parameterization (same set of required outer rels) for the same relation will have the same rowcount estimate. We cache the rowcount estimates to ensure that property, and hopefully save a few cycles too. Doing this makes it practical for add_path_precheck to operate without a rowcount estimate: it need only assume that paths with different parameterizations never dominate each other, which is close enough to true anyway for coarse filtering, because normally a more-parameterized path should yield fewer rows thanks to having more join clauses to apply. In add_path, we do the full nine yards of comparing rowcount estimates along with everything else, so that we can discard parameterized paths that don't actually have an advantage. This fixes some issues I'd found with add_path rejecting parameterized paths on the grounds that they were more expensive than not-parameterized ones, even though they yielded many fewer rows and hence would be cheaper once subsequent joining was considered. To make the same-rowcounts assumption valid, we have to require that any parameterized path enforce *all* join clauses that could be obtained from the particular set of outer rels, even if not all of them are useful for indexing. This is required at both base scans and joins. It's a good thing anyway since the net impact is that join quals are checked at the lowest practical level in the join tree. Hence, discard the original rather ad-hoc mechanism for choosing parameterization joinquals, and build a better one that has a more principled rule for when clauses can be moved. The original rule was actually buggy anyway for lack of knowledge about which relations are part of an outer join's outer side; getting this right requires adding an outer_relids field to RestrictInfo.
-
- 17 3月, 2012 1 次提交
-
-
由 Tom Lane 提交于
In commit 57664ed2 I tried to fix a bug reported by Teodor Sigaev by making non-simple-Var output columns distinct (by wrapping their expressions with dummy PlaceHolderVar nodes). This did not work too well. Commit b28ffd0f fixed some ensuing problems with matching to child indexes, but per a recent report from Claus Stadler, constraint exclusion of UNION ALL subqueries was still broken, because constant-simplification didn't handle the injected PlaceHolderVars well either. On reflection, the original patch was quite misguided: there is no reason to expect that EquivalenceClass child members will be distinct. So instead of trying to make them so, we should ensure that we can cope with the situation when they're not. Accordingly, this patch reverts the code changes in the above-mentioned commits (though the regression test cases they added stay). Instead, I've added assorted defenses to make sure that duplicate EC child members don't cause any problems. Teodor's original problem ("MergeAppend child's targetlist doesn't match MergeAppend") is addressed more directly by revising prepare_sort_from_pathkeys to let the parent MergeAppend's sort list guide creation of each child's sort list. In passing, get rid of add_sort_column; as far as I can tell, testing for duplicate sort keys at this stage is dead code. Certainly it doesn't trigger often enough to be worth expending cycles on in ordinary queries. And keeping the test would've greatly complicated the new logic in prepare_sort_from_pathkeys, because comparing pathkey list entries against a previous output array requires that we not skip any entries in the list. Back-patch to 9.1, like the previous patches. The only known issue in this area that wasn't caused by the ill-advised previous patches was the MergeAppend planning failure, which of course is not relevant before 9.1. It's possible that we need some of the new defenses against duplicate child EC entries in older branches, but until there's some clear evidence of that I'm going to refrain from back-patching further.
-
- 10 2月, 2012 1 次提交
-
-
由 Tom Lane 提交于
Per buildfarm, we sometimes get row-ordering variations in the output. This also makes this query look more like numerous other ones in the same test file.
-
- 08 1月, 2012 1 次提交
-
-
由 Peter Eisentraut 提交于
The original implementation of this interpreted it as a kind of "inheritance" facility and named all the internal structures accordingly. This turned out to be very confusing, because it has nothing to do with the INHERITS feature. So rename all the internal parser infrastructure, update the comments, adjust the error messages, and split up the regression tests.
-
- 20 12月, 2011 1 次提交
-
-
由 Alvaro Herrera 提交于
This makes them enforceable only on the parent table, not on children tables. This is useful in various situations, per discussion involving people bitten by the restrictive behavior introduced in 8.4. Message-Id: 8762mp93iw.fsf@comcast.net CAFaPBrSMMpubkGf4zcRL_YL-AERUbYF_-ZNNYfb3CVwwEqc9TQ@mail.gmail.com Authors: Nikhil Sontakke, Alex Hunsaker Reviewed by Robert Haas and myself
-
- 30 11月, 2011 2 次提交
-
-
由 Tom Lane 提交于
Simple extension of previous patch for CHECK constraints.
-
由 Tom Lane 提交于
This should make it easier to identify which row is problematic when an insert or update is processing many rows. The formatting is similar to that for unique-index violation messages, except that we limit field widths to 64 bytes since otherwise the message could get unreasonably long. (In particular, there's currently no attempt to quote or escape field values that contain commas etc.) Jan Kundrát, reviewed by Royce Ausburn, somewhat rewritten by me.
-
- 09 11月, 2011 2 次提交
-
-
由 Tom Lane 提交于
Ensure that same index gets selected on 32-bit and 64-bit machines. Per buildfarm results.
-
由 Tom Lane 提交于
Add PlaceHolderVar wrappers as needed to make UNION ALL sub-select output expressions appear non-constant and distinct from each other. This makes the world safe for add_child_rel_equivalences to do what it does. Before, it was possible for that function to add identical expressions to different EquivalenceClasses, which logically should imply merging such ECs, which would be wrong; or to improperly add a constant to an EquivalenceClass, drastically changing its behavior. Per report from Teodor Sigaev. The only currently known consequence of this bug is "MergeAppend child's targetlist doesn't match MergeAppend" planner failures in 9.1 and later. I am suspicious that there may be other failure modes that could affect older release branches; but in the absence of any hard evidence, I'll refrain from back-patching further than 9.1.
-