From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Always build a custom plan node's targetlist from the path's pat |
Date: | 2017-04-17 19:29:22 |
Message-ID: | E1d0CKw-0003rf-E0@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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
Branch
------
REL9_6_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/6c73b390b4797c6b81ee4f5d17feda34cfde6ccd
Modified Files
--------------
src/backend/optimizer/plan/createplan.c | 9 +++++++++
1 file changed, 9 insertions(+)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2017-04-17 20:58:00 | pgsql: Tighten up relation kind checks for extended statistics |
Previous Message | Fujii Masao | 2017-04-17 18:20:05 | pgsql: Fix typos in comment and log message. |