Re: Vacuum advice

From: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Mitchell <david(dot)mitchell(at)telogis(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Vacuum advice
Date: 2005-06-23 04:00:18
Message-ID: 1119499218l.14016l.7l@mofo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On 06/22/2005 04:39:00 PM, Tom Lane wrote:
> David Mitchell <david(dot)mitchell(at)telogis(dot)com> writes:
> > However, occasionally we need to import data, and this involves
> > inserting several million rows into a table, but this just
> *cripples*
> > postgres. After the import has been running for a while, simple
> selects
> > take a long time, and strangely, the query planner starts using a
> > sequential scan on a table with millions of items in it. Surely
> inserts
> > shouldn't be doing this? Should I be running a vacuum during the
> import?
>
> PG 8.0 and up should handle this a bit more nicely. Before 8.0 the
> planner looked only at the table size recorded in pg_catalog (the
> relpages and reltuples fields) and so of course it wouldn't react to a
> still-in-progress mass insert. Now it looks at the current actual
> physical table size, and so it should be willing to switch to
> indexscan
> if needed before the import completes.

I've made a habit of disconnecting, analyzing and re-connecting
every so often on mass data loading because any stored
procedures I'm using for the load, including triggers, will not have
their query plans updated to account for the new data.
It's a pain, so I figured I'd ask whether I'm missing
something and this is somehow unnecessary.

Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Akash Garg 2005-06-23 06:08:49 Corrupted index
Previous Message William Yu 2005-06-23 03:56:06 Re: setting up PostgreSQL on Linux RHL9 to allow ODBC connections