Re: partitioned table query question - Mailing list pgsql-general

From Trevor Talbot
Subject Re: partitioned table query question
Date
Msg-id 90bce5730712102050n12e0a994tcc21aaba3e327613@mail.gmail.com
Whole thread Raw
In response to Re: partitioned table query question  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: partitioned table query question
Re: partitioned table query question
List pgsql-general
On 12/10/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Erik Jones <erik@myemma.com> writes:
> > I guess what I don't understand is that given the query
>
> > SELECT COUNT(*)
> > FROM table
> > WHERE some_id=34;
>
> > on a table with the much discussed constraint (34 % 100) = 32 isn't
> > simply evaluated as a one-time filter whenever whatever constraint
> > exclusion code examines child partition tables' constraints.
>
> I'm not sure how else to explain it: the fact that the WHERE clause
> asserts that some operator named "=" will succeed on some_id and 34
> is not sufficient grounds to assume that "some_id % 100" and "34 % 100"
> will give the same result.  Knowing that the "=" operator is a btree
> equality operator gives us latitude to make certain conclusions, but
> not that one, because there is no way to know whether the semantics
> of the particular btree operator class have anything to do with the
> behavior of "%".

Erik is questioning is why it has to assume anything. Why can't it
just execute the expression and find out? On a high level, the
partitioning system looks exactly like partial expression indexes.

pgsql-general by date:

Previous
From: "Brett Neumeier"
Date:
Subject: question about warm standby databases in 8.2.5
Next
From: "Trevor Talbot"
Date:
Subject: Re: partitioned table query question