From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "John D(dot) Burger" <john(at)mitre(dot)org> |
Cc: | Dan Armbrust <daniel(dot)armbrust(dot)list(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Slow Inserts on 1 table? |
Date: | 2005-08-02 16:53:26 |
Message-ID: | 11746.1123001606@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"John D. Burger" <john(at)mitre(dot)org> writes:
> The only annoyance is that the interface I use most often, Python's
> pgdb, runs everything in a transaction, and you can't analyze in a
> transaction.
Hm? We've allowed ANALYZE inside a transaction for a long time.
The real solution to Dan's problem, of course, is to throw away the
cached plan for the FK check and re-plan it once the table sizes have
changed enough to invalidate the plan. Neil Conway was working on
infrastructure for this, but it didn't get done in time for 8.1 ...
maybe it will be there in 8.2.
In the meantime, though, I don't see any mention in the thread of
exactly which PG version Dan is using. If it's 8.0.0 or 8.0.1,
an update would probably help --- we tweaked the rules for never-yet-
vacuumed tables in 8.0.2.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-08-02 16:56:12 | Re: feeding big script to psql |
Previous Message | Tom Lane | 2005-08-02 16:42:40 | Re: Problem with dropping a tablespace |