From: | Leonardo Francalanci <m_lists(at)yahoo(dot)it> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plan time of MASSIVE partitioning ... |
Date: | 2010-10-29 08:48:59 |
Message-ID: | 403806.56889.qm@web29020.mail.ird.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Leonardo Francalanci | 2010-10-29 08:57:20 | Re: plan time of MASSIVE partitioning ... |
Previous Message | Boszormenyi Zoltan | 2010-10-29 08:00:29 | Re: plan time of MASSIVE partitioning ... |