Re: partitioned table query question
От | Trevor Talbot |
---|---|
Тема | Re: partitioned table query question |
Дата | |
Msg-id | 90bce5730712102053p5898c514lb0d441a236f5ce91@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: partitioned table query question ("Trevor Talbot" <quension@gmail.com>) |
Список | 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.
В списке pgsql-general по дате отправления: