Re: A Guide to Constraint Exclusion (Partitioning)

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, bizgres-general(at)pgfoundry(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: A Guide to Constraint Exclusion (Partitioning)
Date: 2005-07-23 18:27:24
Message-ID: 874qalbcoj.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> And this decision is made separately for each child table, so the fact that
> a seqscan might be the best bet for the target partition doesn't stop the
> planner from using the indexscan in other partitions.

That was the detail I was missing. I'm surprised because I actually tested
this before I sent the message and saw a plan like this with a single
sequential scan node despite the three child tables:

staging=> explain select * from _test where a=1;
QUERY PLAN
------------------------------------------------------
Seq Scan on _test (cost=0.00..22.50 rows=5 width=4)
Filter: (a = 1)
(2 rows)

[This is on 7.4, maybe the 8.0 plans are more explicit though I don't recall
any mention of changes in that area]

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2005-07-23 18:27:51 Re: [HACKERS] Enticing interns to PostgreSQL
Previous Message Joshua D. Drake 2005-07-23 18:19:26 Re: [HACKERS] Enticing interns to PostgreSQL