Joshua Rubin wrote:
Hi,
We have a very large, partitioned, table that we often need to query
from new connections, but frequently with similar queries. We have
constraint exclusion on to take advantage of the partitioning. This also
makes query planning more expensive. As a result, the CPU is fu
Hi,
Heikki Linnakangas writes:
> Joshua Rubin wrote:
>> We "hardcode" the parts of the where clause so that the prepared plan
>> will not vary among the possible partitions of the table. The only
>> values that are bound would not affect the planner's choice of table.
>
> Then you would benefit f
Joshua Rubin wrote:
> We "hardcode" the parts of the where clause so that the prepared plan
> will not vary among the possible partitions of the table. The only
> values that are bound would not affect the planner's choice of table.
Then you would benefit from using prepared statements in the clie
Tom,
> If you're depending on constraint exclusion, it's hard to see how plan
> caching could help you at all. The generated plan needs to vary
> depending on the actual WHERE-clause parameters.
Thank you for the reply.
We "hardcode" the parts of the where clause so that the prepared plan
will n
* Heikki Linnakangas (heikki.linnakan...@enterprisedb.com) wrote:
> That's what the OP really should've complained about. If we addressed
> that, so that a generic plan was created that determines which child
> tables can be excluded at run time, there would be no need for the
> persistent plan cac
Tom Lane wrote:
> Joshua Rubin writes:
>> We have a very large, partitioned, table that we often need to query
>> from new connections, but frequently with similar queries. We have
>> constraint exclusion on to take advantage of the partitioning. This also
>> makes query planning more expensive. A
Joshua Rubin writes:
> We have a very large, partitioned, table that we often need to query
> from new connections, but frequently with similar queries. We have
> constraint exclusion on to take advantage of the partitioning. This also
> makes query planning more expensive. As a result, the CPU is
Hi,
We have a very large, partitioned, table that we often need to query
from new connections, but frequently with similar queries. We have
constraint exclusion on to take advantage of the partitioning. This also
makes query planning more expensive. As a result, the CPU is fully
loaded, all the ti
