From: | "Kenneth Cox" <kenstir(at)gmail(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Kevin Kempter" <kevink(at)consistentstate(dot)com> |
Cc: | "PostgreSQL Performance" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: partitioning max() sql not using index |
Date: | 2009-09-09 13:56:53 |
Message-ID: | op.uzzs03uj5ru9c3@kent60.home |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
In case you aren't comfortable running unreleased planner patches from
pgsql-hackers, a workaround was discussed on this list recently:
http://archives.postgresql.org/pgsql-performance/2009-09/msg00036.php
On Wed, 09 Sep 2009 06:05:22 -0400, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Kevin Kempter wrote:
>> Hi all I have a large table (>2billion rows) that's partitioned by date
>> based
>> on an epoch int value. We're running a select max(id) where id is the
>> PK. I
>> have a PK index on each of the partitions, no indexes at all on the base
>> table.
>>
>> If I hit a partition table directly I get an index scan as expected:
>
> The planner isn't smart enough to create the plan you're expecting.
> There was discussion and even a patch posted recently about that:
>
> http://archives.postgresql.org/pgsql-hackers/2009-07/msg01115.php
>
> It seems the thread petered out, but the concept seems sane.
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Kempter | 2009-09-09 14:29:20 | Re: partitioning max() sql not using index |
Previous Message | Reydan Cankur | 2009-09-09 10:15:08 | Best Profiler for PostgreSQL |