From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, 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-26 16:51:52 |
Message-ID: | CA+TgmoYsw3pusDen4_A44c7od+bEAST0eYo+jODtyofR0W2soQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-09-26 17:18:47 | Re: BUG #14825: enum type: unsafe use? |
Previous Message | Alvaro Hernandez | 2017-09-26 16:36:03 | Re: Built-in plugin for logical decoding output |