Re: Proposal: scan key push down to heap [WIP]
От | Andres Freund |
---|---|
Тема | Re: Proposal: scan key push down to heap [WIP] |
Дата | |
Msg-id | 20161201214151.6ctdntqkwavm2jax@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Proposal: scan key push down to heap [WIP] (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Proposal: scan key push down to heap [WIP]
Re: Proposal: scan key push down to heap [WIP] |
Список | pgsql-hackers |
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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: