"Mark Steben" <msteben@xxxxxxxxxxxxxxx> writes:
> I am attempting an update on two new date field columns on a 17 million row
> table. Every row gets updated.
> The update statement is a simple one:
> UPDATE EMAILRCPTS SET ID = ID
> And the update of the new date fields themselves occurs as the result of a
> before trigger.
When you don't show us the trigger, it's hard to make any useful
comment ... but 60 rows/second seems slow enough to suspect that the
trigger is very inefficient.
> There are about 9 indexes on this table although none of them reference the
> date fields so since there are no inserts I don't think they would have an
> impact on the update (I've been wrong before though)
And you are again ... but still, it's awfully slow.
> We are at Postgres 7.4.5.
That's a big problem right there. One thing I can tell you is that it
is sheer folly to set shared_buffers so high on PG 7.x. It wasn't till
about 8.1 that we had buffer management algorithms that were good enough
for lots of buffers. Dial it down to something under 100K buffers. And
think about an update. At the very least you should be on a far more
current 7.4.x release.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
