Le 05/04/2013 16:17, Tom Lane a écrit :
Franck Routier writes:
Le 04/04/2013 21:08, Tom Lane a écrit :
Hmph. Can't see any reason for that to take a remarkably long time to
plan. Can you put together a self-contained test case demonstrating
excessive planning time? What PG version is this,
Le 05/04/2013 16:17, Merlin Moncure a écrit :
Ok, "explain" (without analyze) is measuring plan time only (not
execution time). Can you confirm that's the time we are measuring
(and again, according to what)? Performance issues here are a
different ball game. Please supply precise version#, th
Le 05/04/2013 16:18, Nikolas Everett a écrit :
On Fri, Apr 5, 2013 at 9:55 AM, Franck Routier
mailto:franck.rout...@axege.com>> wrote:
Le 04/04/2013 21:08, Tom Lane a écrit :
Maybe the statistics tables for sandia and saneds are in a bad
shape ? (don't know how to check this).
Le 05/04/2013 16:17, Tom Lane a écrit :
What have you got the statistics targets set to in this database?
Ok, the problem definitely comes from the default_statistics_target
which is obviously too high on the database.
I have experimented with explain on queries with another set of 4 joined
try to increase cpu_tuple_cost to 0.1
On 04/06/2013 03:50, Joe Van Dyk wrote:
If I disable sequential scans, hash joins, and merge joins, the query
plans become the same and performance on the first slow one is much
improved.
Is there something else I can do to avoid this problem?
below also
Julien Cigar wrote:
> try to increase cpu_tuple_cost to 0.1
I agree that's on the right track, but possibly an overly blunt
tool for the job. The following settings are likely to need
adjustment, IMO:
effective_cache_size: People often set this to somewhere in the
range of 50% to 75% of the RA
On 04/06/2013 16:22, Kevin Grittner wrote:
Julien Cigar wrote:
try to increase cpu_tuple_cost to 0.1
I agree that's on the right track, but possibly an overly blunt
tool for the job. The following settings are likely to need
adjustment, IMO:
effective_cache_size: People often set this to so
Franck Routier wrote:
> Ok, the problem definitely comes from the
> default_statistics_target which is obviously too high on the
> database.
> Now... can someone help me understand what happens ? Where can I
> look (in pg_stats ?) to see the source of the problem ? maybe a
> column with a huge l
Franck Routier writes:
> Le 05/04/2013 16:17, Tom Lane a écrit :
>> What have you got the statistics targets set to in this database?
> Ok, the problem definitely comes from the default_statistics_target
> which is obviously too high on the database.
Yeah, eqjoinsel() is O(N^2) in the lengths o
Hi,
Could someone tell m how to measure postgres memory usage.
Is there a pg_* view to measure?
Thank you
NikT
10 matches
Mail list logo
