diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2017-04-17 15:29:00 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2017-04-17 15:29:00 -0400 |
| commit | 6c73b390b4797c6b81ee4f5d17feda34cfde6ccd (patch) | |
| tree | d040afce8863cf7f7ebf200e32ffd8e7d1caadf6 | |
| parent | 1ec36a9eb4c29dc49838319d1e666f66961d757c (diff) | |
| download | postgresql-6c73b390b4797c6b81ee4f5d17feda34cfde6ccd.tar.gz postgresql-6c73b390b4797c6b81ee4f5d17feda34cfde6ccd.zip | |
Always build a custom plan node's targetlist from the path's pathtarget.
We were applying the use_physical_tlist optimization to all relation
scan plans, even those implemented by custom scan providers. However,
that's a bad idea for a couple of reasons. The custom provider might
be unable to provide columns that it hadn't expected to be asked for
(for example, the custom scan might depend on an index-only scan).
Even more to the point, there's no good reason to suppose that this
"optimization" is a win for a custom scan; whatever the custom provider
is doing is likely not based on simply returning physical heap tuples.
(As a counterexample, if the custom scan is an interface to a column store,
demanding all columns would be a huge loss.) If it is a win, the custom
provider could make that decision for itself and insert a suitable
pathtarget into the path, anyway.
Per discussion with Dmitry Ivanov. Back-patch to 9.5 where custom scan
support was introduced. The argument that the custom provider can adjust
the behavior by changing the pathtarget only applies to 9.6+, but on
balance it seems more likely that use_physical_tlist will hurt custom
scans than help them.
Discussion: https://postgr.es/m/e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru
| -rw-r--r-- | src/backend/optimizer/plan/createplan.c | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index 71678d08dcc..6f1166b7039 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -762,6 +762,15 @@ use_physical_tlist(PlannerInfo *root, Path *path, int flags) return false; /* + * Also, don't do it to a CustomPath; the premise that we're extracting + * columns from a simple physical tuple is unlikely to hold for those. + * (When it does make sense, the custom path creator can set up the path's + * pathtarget that way.) + */ + if (IsA(path, CustomPath)) + return false; + + /* * Can't do it if any system columns or whole-row Vars are requested. * (This could possibly be fixed but would take some fragile assumptions * in setrefs.c, I think.) |