Prev: [HACKERS] non-overlapping, consecutive partitions
Next: [HACKERS] permission inconsistency with functions
From: Robert Haas on 25 Jul 2010 19:14
On Sun, Jul 25, 2010 at 6:40 PM, Greg Stark <gsstark(a)mit.edu> wrote:
> 2010/7/25 Robert Haas <robertmhaas(a)gmail.com>:
>> 2010/7/25 PostgreSQL - Hans-J�rgen Sch�nig <postgres(a)cybertec.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

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

From: =?iso-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= on 29 Jul 2010 11:12
hello ...

yeah, this is fairly complicated.

greg:
can you send me how far you got?
i would be curious to see how you have attacked this issue.

i am still in the process of checking the codes.
we somehow have to find a solution for that. otherwise we are in slight trouble here.
it seems we have to solve it no matter what it takes.

many thanks,

hans


On Jul 26, 2010, at 1:14 AM, Robert Haas wrote:

> On Sun, Jul 25, 2010 at 6:40 PM, Greg Stark <gsstark(a)mit.edu> wrote:
>> 2010/7/25 Robert Haas <robertmhaas(a)gmail.com>:
>>> 2010/7/25 PostgreSQL - Hans-J�rgen Sch�nig <postgres(a)cybertec.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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


--
Cybertec Sch�nig & Sch�nig GmbH
Gr�hrm�hlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de


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

First  |  Prev  | 
Pages: 1 2
Prev: [HACKERS] non-overlapping, consecutive partitions
Next: [HACKERS] permission inconsistency with functions