From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: path toward faster partition pruning |
Date: | 2017-09-27 00:39:38 |
Message-ID: | bebcccc9-ca59-d2c1-2194-8afaa9f47c5a@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017/09/27 1:51, Robert Haas wrote:
> On Tue, Sep 26, 2017 at 10:57 AM, Jesper Pedersen
> <jesper(dot)pedersen(at)redhat(dot)com> wrote:
>> One could advocate (*cough*) that the hash partition patch [1] should be
>> merged first in order to find other instances of where other CommitFest
>> entries doesn't account for hash partitions at the moment in their method
>> signatures; Beena noted something similar in [2]. I know that you said
>> otherwise [3], but this is CommitFest 1, so there is time for a revert
>> later, and hash partitions are already useful in internal testing.
>
> Well, that's a fair point. I was assuming that committing things in
> that order would cause me to win the "least popular committer" award
> at least for that day, but maybe not. It's certainly not ideal to
> have to juggle that patch along and keep rebasing it over other
> changes when it's basically done, and just waiting on other
> improvements to land. Anybody else wish to express an opinion?
FWIW, I tend to agree that it would be nice to get the hash partitioning
patch in, even with old constraint exclusion based partition-pruning not
working for hash partitions. That way, it might be more clear what we
need to do in the partition-pruning patches to account for hash partitions.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Abhinav Singh | 2017-09-27 00:46:08 | Re: Logical Replication - test_decoding - unchanged-toast-datum |
Previous Message | Robert Haas | 2017-09-27 00:11:39 | Re: Multicolumn hash indexes |