From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: scan key push down to heap [WIP] |
Date: | 2016-10-28 08:55:44 |
Message-ID: | CAA4eK1KrY7sQ3_UV3uOzLvS8HJP48Xcg+ADGdK5X4rYjo4zkmw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 28, 2016 at 12:16 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2016-10-28 11:23:22 +0530, Amit Kapila wrote:
>
>> I think if we decide to form the scan key from a qual only when qual
>> refers to fixed length column and that column is before any varlen
>> column, the increased cost will be alleviated. Do you have any other
>> idea to alleviate such cost?
>
> Well, that'll also make the feature not particularly useful :(.
>
Yeah, the number of cases it can benefit will certainly reduce, but
still it can be a win wherever it can be used which is not bad.
Another thing that can be considered here is to evaluate if we can use
selectivity as a measure to decide if we can push the quals down. If
the quals are selective, then I think the non-effective caching impact
can be negated and we can in turn see benefits. For example, we can
consider a table with 20 to 40 columns having large number of rows and
try to use different columns in quals and then test it for different
selectivity to see how the performance varies with this patch.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-10-28 11:12:27 | Re: Microvacuum support for Hash Index |
Previous Message | Magnus Hagander | 2016-10-28 08:53:36 | Streaming basebackups vs pg_stat_tmp |