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

Re: non-overlapping, consecutive partitions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
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 23:14:20
Message-ID: AANLkTim1FBZ638MLUpRk6ZU_EVKiea5XCvLQ+VHHUZzv@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Jul 25, 2010 at 6:40 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> 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.

Agreed on all points.

>> 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.

Yeah, I don't fully understand those either.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-07-25 23:17:37
Subject: Re: TwoPO: experimental join order algorithm
Previous:From: Adriano LangeDate: 2010-07-25 22:45:39
Subject: Re: TwoPO: experimental join order algorithm

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