Re: partitioned table query question
Trevor Talbot <quension@gmail.com>
From: "Trevor Talbot" <quension@gmail.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Erik Jones" <erik@myemma.com>, "Mason Hale" <masonhale@gmail.com>, pgsql-general@postgresql.org
Date: 2007-12-11T04:53:10Z
Lists: pgsql-hackers, pgsql-general
On 12/10/07, Trevor Talbot <quension@gmail.com> wrote: > 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. ...Oops. I sit here for 10 minutes pondering it, and figure out the comparison with expression indexes isn't really true 2 seconds after I hit "send". Sigh.