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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: scan key push down to heap [WIP]
Date: 2016-11-14 16:00:49
Message-ID: CA+Tgmoaq3QoO3qC5+h=nXJOLHkuiyr8b47LWpF4L_ETPFWVhfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 13, 2016 at 12:16 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> Problem1: As Andres has mentioned, HeapKeyTest uses heap_getattr,
> whereas ExecQual use slot_getattr().So we can have worst case
> performance problem when very less tuple are getting filter out and we
> have table with many columns with qual on most of the columns.
>
> Problem2. In HeapKeyTest we are under per_query_ctx, whereas in
> ExecQual we are under per_tuple_ctx , so in former we can not afford
> to have any palloc.

Couldn't we just change the current memory context before calling
heap_getnext()? And then change back?

Also, what if we abandoned the idea of pushing qual evaluation all the
way down into the heap and just tried to do HeapKeyTest in SeqNext
itself? Would that be almost as fast, or would it give up most of the
benefits?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2016-11-14 16:14:20 Re: Proposal: scan key push down to heap [WIP]
Previous Message Robert Haas 2016-11-14 15:50:03 Re: Proposal for changes to recovery.conf API