Re: Partitioning

From: James Sewell <james(dot)sewell(at)lisasoft(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: "pierce(at)hogranch(dot)com" <pierce(at)hogranch(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Partitioning
Date: 2015-01-19 07:13:06
Message-ID: CANkGpBtXc3V1JG7maYctF679D-wdGS4FCtKdW2XBDO_zacW-BQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello,

Thanks for the reply. I can write queries which get index scans, but they
are still slow.

Each index is about 2.5GB, I suspect I am trying to read a these into
memory in entirety.

Perhaps there is no way to tune this?

Cheers, james

On Monday, 19 January 2015, Kyotaro HORIGUCHI <
horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:

> Hello,
>
> an 2015 14:13:37 +1100, James Sewell <james(dot)sewell(at)lisasoft(dot)com
> <javascript:;>> wrote in <
> CANkGpBs8GypQ3TQGKdjTD+n-w1rkq5uO97h3tuhg5eWaKR6RbA(at)mail(dot)gmail(dot)com
> <javascript:;>>
> > Sadly not ... I still hit all the tables.
>
> | 5.9.4. Partitioning and Constraint Exclusion
>
> http://www.postgresql.org/docs/9.4/static/ddl-partitioning.html
>
> Constraint exclusion is a mechanism to omit tables that are known
> to have no hit by the query *beforehand* execution. So the
> criteria cannot rely on out of the query itself (and CHECK
> constraints, of course).
>
> Your query uses the result of the WITH-clause-query in the WHERE
> clause which is unknown to the planner so constraint exclusion
> does not work. JOINs don't change the situation.
>
>
> > On Mon, Jan 19, 2015 at 1:54 PM, John R Pierce <pierce(at)hogranch(dot)com
> <javascript:;>> wrote:
> >
> > > On 1/18/2015 5:58 PM, James Sewell wrote:
> > >
> > > WITH idlist as (SELECT id from othertable)
> > > SELECT id from mastertable WHERE id = idlist.id);
> > >
> > >
> > >
> > > select mt.id, ... from mastertable mt join othertable ot on
> mt.id=
> > > ot.id;
> > >
> > > might optimize better.
>
> As the result, the query inevitably scans all the tables, but not
> necessariry in sequqntial scans or simple index scans. The
> suggestion above seeems showing the notation which the planner
> can find the better plans on that premise.
>
> For example, if you have an index on id of one of the two tables,
> (and some other conditions match, of course) index only scan will
> be selected for it and the suggested query will give you a
> seemingly better plan than your query.
>
> regards,
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>
>

--

James Sewell,
PostgreSQL Team Lead / Solutions Architect
______________________________________

Level 2, 50 Queen St, Melbourne VIC 3000

*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099

--

------------------------------
The contents of this email are confidential and may be subject to legal or
professional privilege and copyright. No representation is made that this
email is free of viruses or other defects. If you have received this
communication in error, you may not copy or distribute any part of it or
otherwise disclose its contents to anyone. Please advise the sender of your
incorrect receipt of this correspondence.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John R Pierce 2015-01-19 07:23:14 Re: Partitioning
Previous Message Roxanne Reid-Bennett 2015-01-19 06:33:23 Re: Simple Atomic Relationship Insert