Re: Proposal: scan key push down to heap [WIP]

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: Proposal: scan key push down to heap [WIP]
Дата
Msg-id CAJrrPGdqOe-BB7o+QN_XcM88Z22wCTu3523Mg=MY9GF4g7kRQQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: scan key push down to heap [WIP]  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers


On Fri, Dec 2, 2016 at 8:41 AM, Andres Freund <andres@anarazel.de> wrote:
On 2016-11-30 16:11:23 +0530, Dilip Kumar wrote:
> On Tue, Nov 29, 2016 at 11:21 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Mon, Nov 28, 2016 at 11:17 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >> Actually we want to call slot_getattr instead heap_getattr, because of
> >> problem mentioned by Andres upthread and we also saw in test results.
> >
> > Ah, right.
> >
> >> Should we make a copy of HeapKeyTest lets say ExecKeyTest and keep it
> >> under executor ?
> >
> > Sure.
>
> I have worked on the idea you suggested upthread. POC patch is
> attached.

Hm. I'm more than a bit doubful about this approach. Shouldn't we just
*always* do this as part of expression evaluation, instead of
special-casing for seqscans?

I.e. during planning recognize that an OpExpr can be evaluated as a
scankey and then emit different qual evaluation instructions?  Because
then the benefit can be everywhere, instead of just seqscans.

I'll post my new expression evaluation stuff - which doesn't do this
atm, but makes ExecQual faster in other ways - later this week.  If we
could get the planner (or parse-analysis?) to set an OpExpr flag that
signals that the expression can be evaluated as a scankey, that'd be
easy.


Moved to next CF with "waiting on author" status.

Regards,
Hari Babu
Fujitsu Australia

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: Proposal : For Auto-Prewarm.
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: ParallelFinish-hook of FDW/CSP (Re: Steps inside ExecEndGather)