s fixed, so may be auto tuning it
based on some parameter's can
help such situations.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.pos
erformance-ow...@postgresql.org [mailto:pgsql-performance-
> ow...@postgresql.org] On Behalf Of Amit Kapila
> Sent: Thursday, June 06, 2013 1:41 PM
> To: 'Ghislain ROUVIGNAC'; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Not same plan between static and prepare
e behaviour with both :
> - PostgreSQL 8.4.8 on Windows 2008 (Prod)
> - PostgreSQL 8.4.8 and 8.4.17 on Windows 7 (Dev)
>From PostgreSQL 9.2, it generates plan for prepared query during execution
(Execute command) as well.
So I think you will not face this problem in PostgreSQL 9.2 and abo
ed for all statements are same, if not it
might have some cost for query plan initialization (InitPlan) but again it
should not be that big cost.
How do measure individual bind time cost (is the cost of only server side or
it includes client bind or ..)?
With Regards,
Amit Kapila.
ooses generic plan, so that it doesn't need to generate plan again.
With Regards,
Amit Kapila.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
n future Hash Join might be the best and cheapest way.
Can you try reproducing it with small data or else can you attach your schema
and data for the tables/indexes used in query?
With Regards,
Amit Kapila.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
hashjoin=off;
And see what is the plan it chooses and does it pick up index scan on larger
table?
Could you please output of \d SARS_ACTS and \d SARS_ACTS_RUN?
With Regards,
Amit Kapila.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subs
65.81
> rows=580 width=8)
> Filter: ((algorithm)::text = 'SMAT'::text)
> Does anyone have suggestions about how to speed it up?
Could you please once trying Analyzing both tables and then run the query to
check which plan it uses:
Analyze SARS_ACTS;
Analyze SA
ferent hardware.
> Config changes http://pgsql.privatepaste.com/8acfb9d136
> Any ideas what is going wrong here?
I think you can verify in Logs whether analyze is happening as per your
expectation.
You can set log_autovacuum_min_duration = 0, so that auto_analyze can be logged
everytim
