Romuald Brunet writes:
> After some investigation, we found out that the PostgreSQL server
> (8.1) changed the execution plan (I'm assuming because the number of
> rows increased).
The problem seems to be that the estimate for the number of rows fetched
from dc_post changed drastically --- it was
Romuald Brunet wrote:
> The statistics are at the default value everywhere (10)
Try setting that to 100 and running ANALYZE.
The small size of the sample with the default of 10 happened to land
you with a bad estimate this time. (If the numbers it has were
actually representative of the data
Hello all.
To our surprise this morning, we found a query that used to return
it's result in about 50 ~ 100ms now take about 7.000ms to run.
After some investigation, we found out that the PostgreSQL server
(8.1) changed the execution plan (I'm assuming because the number of
rows increased).
Sin
