Re: partitioned table query question
От | Trevor Talbot |
---|---|
Тема | Re: partitioned table query question |
Дата | |
Msg-id | 90bce5730712102050n12e0a994tcc21aaba3e327613@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: partitioned table query question (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: partitioned table query question
Re: partitioned table query question |
Список | 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 по дате отправления: