Цитат от Tom Lane :
zz...@mail.bg writes:
I am running a relativ complex query on pg 8.3.5 and have (possible)
wrong query plan.
...
If I run the query without thle last part : and n.num like '191%'
it work ok as speed ~ 30 sec on not very big db.
If I run the full query it take very long time
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
decibel writes:
> On Aug 19, 2009, at 7:45 PM, Jaime Casanova wrote:
>> AFAIUI, work_mem is used for some operations (sort, hash, etc) for
>> avoiding the use of temp files on disk...
>>
>> In a client server i'm monitoring (pg 8.3.7, 32GB of ram) work_mem is
>> set to 8MB, however i'm seeing a l
On Aug 19, 2009, at 7:45 PM, Jaime Casanova wrote:
AFAIUI, work_mem is used for some operations (sort, hash, etc) for
avoiding the use of temp files on disk...
In a client server i'm monitoring (pg 8.3.7, 32GB of ram) work_mem is
set to 8MB, however i'm seeing a lot of temp files (>3 in 4 ho
* 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
zz...@mail.bg writes:
> I am running a relativ complex query on pg 8.3.5 and have (possible)
> wrong query plan.
> ...
> If I run the query without thle last part : and n.num like '191%'
> it work ok as speed ~ 30 sec on not very big db.
> If I run the full query it take very long time to go
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
Hi,
I am running a relativ complex query on pg 8.3.5 and have (possible)
wrong query plan.
My select :
explain analyze select d.ids from a_doc d join a_sklad s on
(d.ids=s.ids_doc) join a_nomen n on (n.ids=s.ids_num) join a_nom_gr
nmgr on (nmgr.ids=n.ids_grupa) join a_gar_prod_r gr
11 matches
Mail list logo
