Re: Partitions and joins lead to index lookups on all partitions - Mailing list pgsql-performance

From Ondrej Ivanič
Subject Re: Partitions and joins lead to index lookups on all partitions
Date
Msg-id CAM6mieK0rNca9Gzs330upTjdY09rQ175UecjEf40-2o8hGaOew@mail.gmail.com
Whole thread Raw
In response to Partitions and joins lead to index lookups on all partitions  (Christiaan Willemsen <cwillemsen@technocon.com>)
Responses Re: Partitions and joins lead to index lookups on all partitions  (voodooless <cwillemsen@technocon.com>)
List pgsql-performance
Hi,

On 8 December 2011 02:15, Christiaan Willemsen <cwillemsen@technocon.com> wrote:
> Currently, we are running into serious performance problems with our
> paritioning setup, because index lookups are mostly done on allpartions, in
> stead of the one partition it should know that it can find the needed row.

Planner is not very smart about partitions. If expression can't be
evaluated to constant (or you use stable/volatile function) during
planning time then you get index/seq scan across all partitions.

> Now when I join the two:
>
> select part_table.* from part_table
>
> join ref_table on (ref_table.part_table_id = part_table.id and group_id =
> 12321)

I had to add extra where conditions which help to decide the right
partitions i.e. where part_col between X and Y. It would be quite hard
to this in your case. You can execute another query like
- select part_table_id from ref_table where group_id = 12321
- or select min(part_table_id), max(part_table_id) from ref_table
where group_id = 12321
and the use in() or between X and Y in second query (so have to
execute two queries).

--
Ondrej Ivanic
(ondrej.ivanic@gmail.com)

pgsql-performance by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: autovacuum, any log?
Next
From: Havasvölgyi Ottó
Date:
Subject: Re: Response time increases over time