Re: Partitioning

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: francois(at)teksol(dot)info
Cc: james(dot)sewell(at)lisasoft(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: Partitioning
Date: 2015-01-20 01:12:35
Message-ID: 20150120.101235.127358568.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi,

19 Jan 2015 06:58:21 -0500, François Beausoleil <francois(at)teksol(dot)info> wrote in <CC2FD572-320A-4225-B98C-48F20992527C(at)teksol(dot)info>
>
> > Le 2015-01-18 à 20:58, James Sewell <james(dot)sewell(at)lisasoft(dot)com> a écrit :
> >
> > Hello,
> >
> > I am using partitioning with around 100 sub-tables. Each sub-table is around 11GB and partitioned on the 'id' column. I have an index on the id column on each sub-table.
> >
> > Is it possible to get a query like the following working using constraint exclusion, or am I doomed to do index/sequential scans of every sub-table?
> >
> > I want to select all rows which have an id which is in another query, so something like:
> >
> > WITH idlist as (SELECT id from othertable)
> > SELECT id from mastertable WHERE id = idlist.id);
> >
> > I am guessing that I am not getting constraint exclusion to work as the planner doesn't know the outcome of my subquery at plan time?
> >
> How many rows in idlist? Can you do two queries? Fetch the ids, then call the 2nd query with those values hard-coded in the query.
>
> If necessary, and you know where each partition starts, tou could sort in the app and query the correct ranges, in multiple queries.

The strategy's effectiveness is depends mainly on how many ids
come from the othertable. It wins if fewer than certain number or
converged in a few partitions, however, straight joins will win
elsewise.

The result of EXPLAIN ANALYZE might draw more precise advices.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Melvin Davidson 2015-01-20 02:12:49 Re: Getting truncated queries from pg_stat_statements
Previous Message Tim Uckun 2015-01-19 23:41:25 Re: Getting truncated queries from pg_stat_statements