From: | Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl> |
---|---|
To: | Bill Thoen <bthoen(at)gisnet(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Partitioned Database and Choosing Subtables |
Date: | 2011-03-16 07:40:52 |
Message-ID: | 85AA656D-2E4E-47C0-9EF9-831EF101A514@solfertje.student.utwente.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>> 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.
OTOH, using prepared statements the query plan is stored with placeholders for the parameter values at the moment the PREPARE executes. That query plan is already set in stone - it will be a generic plan that can't be optimised for different values of parameters anymore. Not what you want.
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.
!DSPAM:737,4d8069c0235881427912932!
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2011-03-16 07:46:37 | Re: how to use savepoint and rollback in function |
Previous Message | Alban Hertroys | 2011-03-16 07:35:46 | Re: A join of 2 tables with sum(column) > 30 |