Re: plan time of MASSIVE partitioning ... - Mailing list pgsql-hackers

From Leonardo Francalanci
Subject Re: plan time of MASSIVE partitioning ...
Date
Msg-id 403806.56889.qm@web29020.mail.ird.yahoo.com
Whole thread Raw
In response to Re: plan time of MASSIVE partitioning ...  (Boszormenyi Zoltan <zb@cybertec.at>)
Responses Re: plan time of MASSIVE partitioning ...
Re: plan time of MASSIVE partitioning ...
List pgsql-hackers
> On the other hand, if I use a similar test case to my original  one
> (i.e. the tables are much wider) then the query planning takes
> 1.42  seconds in 9.1 with this patch instead of about 4.7 seconds
> as we observed it  using PostgreSQL 9.0.0. The beginning of the gprof
> output now looks like  this:

Hi,

I'm really interested in this patch.

I tried a simple test case:

create table t (a integer, b text);

DO $$DECLARE i int;
BEGIN           FOR i IN 0..9000 LOOP               EXECUTE 'create table t' || i || ' ( CHECK (a >' || i*10 || '
and a <= ' || (i+1)*10 || ' ) ) INHERITS (t)';  EXECUTE 'create index tidx' || i || ' ON t' || i || '  (a)';
END LOOP;
END$$;

explain select * from t where a > 1060 and a < 1090;

but I don't get any gain from the patch... explain time is still around 250 ms.

Tried with 9000 partitions, time is still 2 secs.


Maybe I've missed completely the patch purpose?


(I tried the test case at

http://archives.postgresql.org/message-id/4CBD9DDC.4040304@cybertec.at

and that, in fact, gets a boost with this patch).



Leonardo





pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: plan time of MASSIVE partitioning ...
Next
From: Leonardo Francalanci
Date:
Subject: Re: plan time of MASSIVE partitioning ...