From: | Gabriele Turchi <gabriele(dot)turchi(at)l39a(dot)com> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org, Marco Colombo <marco(at)esiway(dot)net> |
Subject: | Re: Big differences in plans between 8.0 and 8.1 |
Date: | 2006-07-18 07:25:40 |
Message-ID: | 1153207541.3323.10.camel@apollo5.casa.intranet |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Il giorno dom, 16/07/2006 alle 11.08 -0700, Joe Conway ha scritto:
> Gabriele Turchi wrote:
> > Il giorno sab, 15/07/2006 alle 13.04 -0700, Joe Conway ha scritto:
> >>Why not just periodically (once an hour?) run "ANALYZE registrazioni;"
> >>during the day. This will only update the statistics, and should be very
> >>low impact.
> >
> > This is my "solution" too... but: is enough? Or else: there is a better
> > way to do this? If the performance in the better case is 50 times faster
> > than the worse case, during an hour (50/100 record inserted in
> > "registrazioni") how much the performance can fall before the new
> > "ANALYZE" is run? Otherwise, running ANALYZE more frequently can badly
> > affect the overall performance?
>
> One thing I noticed is that in both plans there is a seq scan on
> registrazioni. Given that performance degrades so quickly as records are
> inserted into registrazioni, I'm wondering if you're missing an index.
> What indexes do you have on registrazioni?
>
> Joe
No one. The application was not fine-tuned, because the original
performance (under 8.0) was "more than enough". I thought that creating
an index on a table with no more than some hundred of records was not
useful...
My biggest doubt is anyway related to the very big difference between
the plans in 8.0 and 8.1 under the same conditions.
Thank you,
Gabriele
From | Date | Subject | |
---|---|---|---|
Next Message | Kapadaidakis Yannis | 2006-07-18 09:25:44 | Re: Problem with bitmap-index-scan plan |
Previous Message | Rusty Conover | 2006-07-18 06:56:13 | Re: Temporary table retains old contents on update eventually causing slow temp file usage. |