postgresql

mirror of https://git.postgresql.org/git/postgresql.git synced 2024-08-29 21:47:19 +02:00

Go to file

Tom Lane 8b9d323cb9 Refactor planning of projection steps that don't need a Result plan node. The original upper-planner-pathification design (commit `3fc6e2d7f5`) assumed that we could always determine during Path formation whether or not we would need a Result plan node to perform projection of a targetlist. That turns out not to work very well, though, because createplan.c still has some responsibilities for choosing the specific target list associated with sorting/grouping nodes (in particular it might choose to add resjunk columns for sorting). We might not ever refactor that --- doing so would push more work into Path formation, which isn't attractive --- and we certainly won't do so for 9.6. So, while create_projection_path and apply_projection_to_path can tell for sure what will happen if the subpath is projection-capable, they can't tell for sure when it isn't. This is at least a latent bug in apply_projection_to_path, which might think it can apply a target to a non-projecting node when the node will end up computing something different. Also, I'd tied the creation of a ProjectionPath node to whether or not a Result is needed, but it turns out that we sometimes need a ProjectionPath node anyway to avoid modifying a possibly-shared subpath node. Callers had to use create_projection_path for such cases, and we added code to them that knew about the potential omission of a Result node and attempted to adjust the cost estimates for that. That was uncertainly correct and definitely ugly/unmaintainable. To fix, have create_projection_path explicitly check whether a Result is needed and adjust its cost estimate accordingly, though it creates a ProjectionPath in either case. apply_projection_to_path is now mostly just an optimized version that can avoid creating an extra Path node when the input is known to not be shared with any other live path. (There is one case that create_projection_path doesn't handle, which is pushing parallel-safe expressions below a Gather node. We could make it do that by duplicating the GatherPath, but there seems no need as yet.) create_projection_plan still has to recheck the tlist-match condition, which means that if the matching situation does get changed by createplan.c then we'll have made a slightly incorrect cost estimate. But there seems no help for that in the near term, and I doubt it occurs often enough, let alone would change planning decisions often enough, to be worth stressing about. I added a "dummypp" field to ProjectionPath to track whether create_projection_path thinks a Result is needed. This is not really necessary as-committed because create_projection_plan doesn't look at the flag; but it seems like a good idea to remember what we thought when forming the cost estimate, if only for debugging purposes. In passing, get rid of the target_parallel parameter added to apply_projection_to_path by commit `54f5c5150`. I don't think that's a good idea because it involves callers in what should be an internal decision, and opens us up to missing optimization opportunities if callers think they don't need to provide a valid flag, as most don't. For the moment, this just costs us an extra has_parallel_hazard call when planning a Gather. If that starts to look expensive, I think a better solution would be to teach PathTarget to carry/cache knowledge of parallel-safety of its contents.		2016-06-21 18:38:20 -04:00
config	Update config.guess and config.sub	2016-05-06 14:02:44 -04:00
contrib	pg_trgm's set_limit() function is parallel unsafe, not parallel restricted.	2016-06-20 11:29:54 -04:00
doc	Stamp 9.6beta2.	2016-06-20 16:23:47 -04:00
src	Refactor planning of projection steps that don't need a Result plan node.	2016-06-21 18:38:20 -04:00
.dir-locals.el	emacs: Set indent-tabs-mode in perl-mode	2015-04-12 23:53:23 -04:00
.gitattributes	Fix whitespace and remove obsolete gitattributes entry	2016-03-13 16:03:13 -04:00
.gitignore	Add .gitignore entries for AIX-specific intermediate build artifacts.	2015-07-08 20:44:22 -04:00
aclocal.m4	Replace our hacked version of ax_pthread.m4 with latest upstream version.	2015-07-08 20:36:06 +03:00
configure	Stamp 9.6beta2.	2016-06-20 16:23:47 -04:00
configure.in	Stamp 9.6beta2.	2016-06-20 16:23:47 -04:00
COPYRIGHT	Update copyright for 2016	2016-01-02 13:33:40 -05:00
GNUmakefile.in	Fix distclean/maintainer-clean targets to remove top-level tmp_install dir.	2015-05-13 18:48:05 -04:00
HISTORY	Improve text of stub HISTORY file.	2014-02-12 18:16:17 -05:00
Makefile	Allow make check in PL directories	2011-02-15 06:52:12 +02:00
README	Don't generate plain-text HISTORY and src/test/regress/README anymore.	2014-02-10 20:48:04 -05:00
README.git	Don't generate plain-text HISTORY and src/test/regress/README anymore.	2014-02-10 20:48:04 -05:00

README

PostgreSQL Database Management System
=====================================

This directory contains the source code distribution of the PostgreSQL
database management system.

PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions, foreign keys, subqueries, triggers, user-defined types
and functions.  This distribution also contains C language bindings.

PostgreSQL has many language interfaces, many of which are listed here:

	http://www.postgresql.org/download

See the file INSTALL for instructions on how to build and install
PostgreSQL.  That file also lists supported operating systems and
hardware platforms and contains information regarding any other
software packages that are required to build or run the PostgreSQL
system.  Copyright and license information can be found in the
file COPYRIGHT.  A comprehensive documentation set is included in this
distribution; it can be read as described in the installation
instructions.

The latest version of this software may be obtained at
http://www.postgresql.org/download/.  For more information look at our
web site located at http://www.postgresql.org/.