Re: [HACKERS] [POC] hash partitioning - Mailing list pgsql-hackers

From Jesper Pedersen
Subject Re: [HACKERS] [POC] hash partitioning
Date
Msg-id 77d48599-a2f4-5457-1385-96af25fda63a@redhat.com
Whole thread Raw
In response to Re: [HACKERS] [POC] hash partitioning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] [POC] hash partitioning
List pgsql-hackers
On 09/14/2017 01:52 PM, Robert Haas wrote:
> On Thu, Sep 14, 2017 at 1:07 PM, Jesper Pedersen
> <jesper.pedersen@redhat.com> wrote:
>> Yeah, it would be nice to have a syntax like
>>
>> ) PARTITION BY HASH (col) WITH (AUTO_CREATE = 64);
>>
>> But then there also needs to be a way to create the 64 associated indexes
>> too for everything to be easy.
> 
> Well, for that, there's this proposal:
> 
> http://postgr.es/m/c8fe4f6b-ff46-aae0-89e3-e936a35f0cfd@postgrespro.ru
> 
> As several people have right pointed out, there's a lot of work to be
> done on partitioning it to get it to where we want it to be.  Even in
> v10, it's got significant benefits, such as much faster bulk-loading,
> but I don't hear anybody disputing the notion that a lot more work is
> needed.  The good news is that a lot of that work is already in
> progress; the bad news is that a lot of that work is not done yet.
> 
> But I think that's OK.  We can't solve every problem at once, and I
> think we're moving things along here at a reasonably brisk pace.  That
> didn't stop me from complaining bitterly to someone just yesterday
> that we aren't moving faster still, but unfortunately EnterpriseDB has
> only been able to get 12 developers to do any work at all on
> partitioning this release cycle, and 3 of those have so far helped
> only with review and benchmarking.  It's a pity we can't do more, but
> considering how many community projects are 1-person efforts I think
> it's pretty good.
> 
> To be clear, I know you're not (or at least I assume you're not)
> trying to beat me up about this, just raising a concern, and I'm not
> trying to beat you up either, just let you know that it is definitely
> on the radar screen but not there yet.
> 

Definitely not a complain about the work being done.

I think the scope of Amul's and others work on hash partition support is 
where it needs to be. Improvements can always follow in future release.

My point was that is easy to script the definition of the partitions and 
their associated indexes, so it is more important to focus on the core 
functionality with the developer / review resources available.

However, it is a little bit difficult to follow the dependencies between 
different partition patches, so I may not always provide sane feedback, 
as seen in [1].

[1] 
https://www.postgresql.org/message-id/579077fd-8f07-aff7-39bc-b92c855cdb70%40redhat.com

Best regards, Jesper


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [POC] hash partitioning
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] [PATCH] Call RelationDropStorage() for broader rangeof object drops.