Skip site navigation (1) Skip section navigation (2)

Re: non-overlapping, consecutive partitions

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Subject: Re: non-overlapping, consecutive partitions
Date: 2010-07-25 22:40:43
Message-ID: AANLkTimdmLiSgJmnFS+WHQ6cK7s0UtVRwayUKDLP37Ty@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2010/7/25 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 2010/7/25 PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>:
>>
>> On Jul 25, 2010, at 11:56 AM, Martijn van Oosterhout wrote:
>>
>>> I think the right way to approach this is to teach the planner about
>>> merge sorts.

For what it's worth I think this is a belt-and-suspenders type of
situation where we want two solutions which overlap somewhat.

I would really like to have merge-append nodes because there are all
sorts of plans where append nodes destroying the ordering of their
inputs eliminates a lot of good plans. Those cases can be UNION ALL
nodes, or partitions where there's no filter on the partition key at
all.

But for partitioned tables like the OPs the "real" solution would be
to have more structured meta-data about the partitions that allows the
planner to avoid needing the merge at all. It would also means the
planner wouldn't need to look at every node; it could do a binary
search or equivalent for the right partitions.

> Greg Stark had a patch to do this a while back called merge append,
> but it never got finished...

I was basically in over my head with the planner. I don't understand
how equivalent classes are used or should be used and didn't
understand the code I was pointed at as being analogous. It's probably
not so complicated as all that, but I never really wrapped my head
around it and moved onto tasks I could make more progress on.

-- 
greg

In response to

Responses

pgsql-hackers by date

Next:From: Adriano LangeDate: 2010-07-25 22:45:39
Subject: Re: TwoPO: experimental join order algorithm
Previous:From: Robert HaasDate: 2010-07-25 21:44:00
Subject: Re: TwoPO: experimental join order algorithm

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group