I'm pretty sure that the table was empty before doing the load, but I
gave this a shot. It didn't have an impact on the results.
The behavior also persists across a dump/reload of the table into a
new install on a different machine. IIRC dump/reload rebuilds
indexes from scratch.
Steve
At
1mb, whereas the copy has 1021 mb and no space for indexes.
Steve
At 03:28 PM 10/4/2006, Tom Lane wrote:
Steve Peterson <[EMAIL PROTECTED]> writes:
> If I run the statement:
> (1): UPDATE voter SET gender = 'U';
> on the table in this condition, the query effectivel
I'm having an interesting (perhaps anomalous) variability in UPDATE
performance on a table in my database, and wanted to see if there was
any interest in looking further before I destroy the evidence and move on.
The table, VOTER, contains 3,090,013 rows and each row is about 120
bytes wide.
Is there a reason you can't rewrite your SELECT like:
SELECT UUID FROM MDM.KEYWORDS_INFO WHERE KEYWORDS_ID IN (a, b, c, d)
Even doing them 100 at a time will make a big difference; you should
put as many in the list as pgsql supports. I'm assuming that there's
an index over KEYWORDS_ID.
Re