Re: pgsql: Support partition pruning at execution time
От | David Rowley |
---|---|
Тема | Re: pgsql: Support partition pruning at execution time |
Дата | |
Msg-id | CAKJS1f_EdwgVAnBWM8Yw2wAmk6X-xS71KaJ2yShyOQ3fbLYzVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Support partition pruning at execution time (David Rowley <david.rowley@2ndquadrant.com>) |
Список | pgsql-committers |
On 8 April 2018 at 11:26, David Rowley <david.rowley@2ndquadrant.com> wrote: > On 8 April 2018 at 10:59, David Rowley <david.rowley@2ndquadrant.com> wrote: >> Sometimes I see: >> >> relname | relallvisible >> ---------+--------------- >> tprt_1 | 0 >> tprt_2 | 1 >> >> Other times I see: >> >> relname | relallvisible >> ---------+--------------- >> tprt_1 | 0 >> tprt_2 | 0 > > The minimum set of commands I can find to recreate this are: > > drop table if exists tprt; > create table tprt (col1 int) partition by range (col1); > create table tprt_1 partition of tprt for values from (1) to (5001); > create index tprt1_idx on tprt_1 (col1); > insert into tprt values (10), (20), (501), (502), (505), (1001), (4500); > vacuum tprt; select relname,relallvisible from pg_Class where relname > like 'tprt%' and relkind = 'r'; > > I get relallvisible = 0 once in maybe 20 or so attempts. > > I didn't manage to get the same without a partitioned table. Anyway, this does not seem related to this patch. So no point in the build farm blaming it. There might be some reasonable explanation for this that I just can't think of now. I've attached a patch which gets rid of the index only scans in the tests. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-committers по дате отправления: