Hi Jeff Unfortunately it's not just the one particular query, there's no pattern that I can see besides the time they're being executed.
We did go from Autovac only to nightly vac. I'm going to implement autovac again, we've been operating without for a few months now. Will run both nightly manual and autovac to see how things go. On a side not, we're not doing a vacuumdb, but individual vacuum analyze statements on each table. Not sure if that makes any difference. On Mon, Apr 7, 2014 at 9:13 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Mon, Apr 7, 2014 at 3:58 AM, Rebecca Clarke <r.clark...@gmail.com>wrote: > >> Thanks, I'll run the EXPLAIN (ANALYZE, BUFFERS) today and tomorrow >> morning. I just tried it now on a query that took 109035.116 ms this >> morning (Which returns one row). It has returned 675.496 ms. I will run >> on this same query at 5am tomorrow. Thank you. >> > > If the problem is largely encapsulated by that one query, I'd just write a > cron job to execute that query every morning 15 minutes before you open for > business. > > >> >> At present we run pg_dumps every three hours. >> >> We orginally found autovacuum too intrusive so switched to manual. We've >> had no problems with performance at all, only this. We're going to turn >> autovacuum back on to see if it makes any impact to this particular issue. >> > > Did you go from 'Autovacuum only' to 'nightly vacuum, no autovac' in one > step? Mostly likely adding the nightly vacuum while leaving autovac on > would have solved the problem, while being less likely to cause other > problems. (This is a side note--having autovac off is unlikely to be > causing the particular problem you are reporting here.) > > Cheers, > > Jeff >
