- 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>
-
- 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
-
- 13 12月, 2018 1 次提交
-
-
由 Daniel Gustafsson 提交于
The Greenplum specific error handling via ereport()/elog() calls was in need of a unification effort as some parts of the code was using a different messaging style to others (and to upstream). This aims at bringing many of the GPDB error calls in line with the upstream error message writing guidelines and thus make the user experience of Greenplum more consistent. The main contributions of this patch are: * errmsg() messages shall start with a lowercase letter, and not end with a period. errhint() and errdetail() shall be complete sentences starting with capital letter and ending with a period. This attempts to fix this on as many ereport() calls as possible, with too detailed errmsg() content broken up into details and hints where possible. * Reindent ereport() calls to be more consistent with the common style used in upstream and most parts of Greenplum: ereport(ERROR, (errcode(<CODE>), errmsg("short message describing error"), errhint("Longer message as a complete sentence."))); * Avoid breaking messages due to long lines since it makes grepping for error messages harder when debugging. This is also the de facto standard in upstream code. * Convert a few internal error ereport() calls to elog(). There are no doubt more that can be converted, but the low hanging fruit has been dealt with. Also convert a few elog() calls which are user facing to ereport(). * Update the testfiles to match the new messages. Spelling and wording is mostly left for a follow-up commit, as this was getting big enough as it was. The most obvious cases have been handled but there is work left to be done here. Discussion: https://github.com/greenplum-db/gpdb/pull/6378Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io> Reviewed-by: NHeikki Linnakangas <hlinnakangas@pivotal.io>
-
- 13 11月, 2018 1 次提交
-
-
由 Pengzhou Tang 提交于
This commit fixes wrong results with correlated queries (#6074), the issue is introduced by commit 2c011ce4 in which it made a bad decision to call ExecSquelchNode() in RESULT node. The original thought in 2c011ce4 is, once the one-time filter qual of a RESULT node is evaluated to be false, we no longer need to fetch tuple from child node, so it's safe to send a stop message to source QE senders. Then if the RESULT node is rescanned, one-time filter is revaluated to be true, RESULT node need to fetch tuple from child node, however, the QE senders has been stopped and some tuples are missed. So the first step is reverting the changes in 2c011ce4 and then add a new test case.
-
- 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>
-
- 30 6月, 2018 1 次提交
-
-
由 Shreedhar Hardikar 提交于
-
- 11 11月, 2017 1 次提交
-
-
由 Dhanashree Kashid 提交于
This function had diverged a lot from upstream; post subselect merge. One of the main reason is that upstream has lot of restrictive checks which prevent pull-up of EXISTS/NOT EXISTS. GPDB handles them differently; thus producing a join/initplan or a one-time filter. The cases that GPDB handles and for which we have not ported the checks from upstream are as follows: - AGG with limit count with/without offset - HAVING clause without AGG - AGG without HAVING clause For other conditions, we bail out as upstream. Hence we have added checks differently for having and aggs inside simplify_EXISTS_query. Rest of the code is similar to upstream. Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>
-
- 27 9月, 2017 1 次提交
-
-
由 Dhanashree Kashid 提交于
After the introduction of `placeholder` mechanism, we see some changes in the plan. These are all good changes in that we remove the redundant `NOTIN_subquery` subquery scan nodes: Before ``` ... -> Broadcast Motion 3:3 (slice1; segments: 3) -> Subquery Scan "NotIn_SUBQUERY" -> Seq Scan on subselect_tbl Filter: f3 IS NOT NULL ``` After ``` ... -> Broadcast Motion 3:3 (slice1; segments: 3) -> Seq Scan on subselect_tbl Filter: f3 IS NOT NULL ``` New plans have better cost since we will not be executing subquery scan for each tuple coming from its OUTER. We are now consistent with plans produced for same queries with IN instead of NOT IN. Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>
-
- 18 4月, 2017 1 次提交
-
-
由 Venkatesh Raghavan 提交于
-
- 07 1月, 2017 1 次提交
-
-
In a few cases planner makes a wrong decision about converting a correlated subquery into a join, which results in: 0. Wrong results because the transformation was not equivalent; OR 0. Execution errors because the plans contained invalid params (across slices) This commit adds tests for those cases.
-
- 19 12月, 2016 1 次提交
-
-
由 Daniel Gustafsson 提交于
The different kinds of NOTICE messages regarding table distribution were using a mix of upper and lower case for 'DISTRIBUTED BY'. Make them consistent by using upper case for all messages and update the test files, and atmsort regexes, to match.
-
- 09 9月, 2016 1 次提交
-
-
由 Venkatesh Raghavan 提交于
Enable NOT IN subquery when merge join on that particular data type is not supported [#120384087] (#1099)
-
- 03 9月, 2016 2 次提交
-
-
-
This commit - backs out the test addition in 9c98a4f8 - adds the test to a more appropriate place: `bfv_subquery`
-
- 18 2月, 2016 2 次提交
-
-
由 Haisheng Yuan 提交于
-
由 Venkatesh Raghavan 提交于
-