From: | Bill Thoen <bthoen(at)gisnet(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Partitioned Database and Choosing Subtables |
Date: | 2011-03-16 10:25:09 |
Message-ID: | 4D809005.2080303@gisnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 3/16/2011 12:40 AM, Alban Hertroys wrote:
>>> Try using "dynamic" sql:
>>>
>>> EXECUTE 'SELECT lions, tigers, bears, statecode FROM WildLife WHERE
>>> state_pt = ' || statecode INTO ...;
>> Thanks Igor. It was a nice try -- and I thought it would work, but the Planner had other plans. Basically, I tried the interactive method using a PREPARE statement with one text parammeter followed by an EXECUTE statement. Unfortunately, the query still went rummaging across the entire database sequentially.
>
> That's not the same as using dynamic SQL. In fact, that would behave just like your previous, problematic, query.
>
> Dynamic SQL makes that the planner sees a new query each time, that needs to be planned from scratch.
>
Thanks for explaining this. I think I can just see what you mean. I can
also see that I'm way out of my depth here. It's just so much fun when
you mix deadlines with ignorance.
> If you can't see the forest for the trees,
> cut the trees and you'll see there is no forest.
Good point. I'm feeling a bit chainsaw-ish right now.
--
*Bill Thoen*
GISnet - www.gisnet.com
303-786-9961
From | Date | Subject | |
---|---|---|---|
Next Message | maxxedit@gmail.com | 2011-03-16 10:43:37 | writing a plpgsql query for the first time |
Previous Message | Jo | 2011-03-16 09:16:38 | Re: Postgres 8.3 vs. 8.4 - Query plans and performance |