Re: Aggregate leads to superfluous projection from the scan
От | Zhihong Yu |
---|---|
Тема | Re: Aggregate leads to superfluous projection from the scan |
Дата | |
Msg-id | CALNJ-vQFBrpm+rNo7EyWd1AN4oe5wo4qNXLvvS6AHbwhF92o6A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Aggregate leads to superfluous projection from the scan (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Aggregate leads to superfluous projection from the scan
|
Список | pgsql-hackers |
On Fri, Jul 8, 2022 at 12:30 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ibrar Ahmed <ibrar.ahmad@gmail.com> writes:
> I give a quick look and I think in case whenever data is extracted from the
> heap it shows all the columns. Therefore when columns are extracted from
> the index only it shows the indexed column only.
This is operating as designed, and I don't think that the proposed
patch is an improvement. The point of use_physical_tlist() is that
returning all the columns is cheaper because it avoids a projection
step. That's true for any case where we have to fetch the heap
tuple, so IndexScan is included though IndexOnlyScan is not.
Now, that's something that was true a decade or more ago.
There's been considerable discussion recently about cases where
it's not true anymore, for example with columnar storage or FDWs,
and so we ought to invent a way to prevent createplan.c from
doing it when it would be counterproductive. But just summarily
turning it off is not an improvement.
regards, tom lane
Hi,
In createplan.c, there is `change_plan_targetlist`
change_plan_targetlist(Plan *subplan, List *tlist, bool tlist_parallel_safe)
But it doesn't have `Path` as parameter.
So I am not sure whether the check of non-returnable columns should be done in change_plan_targetlist().
bq. for example with columnar storage or FDWs,
Yeah. The above is the case where I want to optimize.
Cheers
В списке pgsql-hackers по дате отправления: