Re: path toward faster partition pruning

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

In response to

Responses

Browse pgsql-hackers by date

  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