From: | Scara Maccai <m_lists(at)yahoo(dot)it> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: totally different plan when using partitions + request |
Date: | 2009-08-13 10:53:33 |
Message-ID: | 342945.47862.qm@web24606.mail.ird.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I'm still looking into it, but it seems the difference in the 2 plans is due to the fact that when using partitions, the planner adds the time it would take to index-scan the empty "root" table.
But that table will never contain any data...
Is there any chance to have the partitioning mechanism know that a table will always contain no data, because only inheriting table will contain data?
Having the planner line:
-> Index Scan using teststscell13_pkey on teststscell13 data1 (cost=0.0..3.9 rows=1 width=16) (actual time=0.006..0.006 rows=0 loops=285)
doesn't make any sense: that table will never have any data.
I'd like to have a way to tell that to Postgresql...
Something like:
CREATE TABLE tabroot
(...) WITH (NODATA)
So that it will stop scanning the empty table every single loop...
And every time you try to insert directly into tabroot you get an error...
From | Date | Subject | |
---|---|---|---|
Next Message | Scara Maccai | 2009-08-13 11:07:13 | R: multiple paramters in aggregate function |
Previous Message | Sim Zacks | 2009-08-13 10:51:49 | multiple paramters in aggregate function |