"Josh Berkus" <[EMAIL PROTECTED]> writes:
> Thanks for the response. Chris Ruprecht and I got into an off-list
> conversation and basically determined that the problem is 90% likely to
> be disk access time.
Hmm. Can you cut the amount of disk access by reducing the number of
updates that you d
Tom,
> I kinda doubt it. More likely sources of trouble involve the
> optimizer
> picking bad plans because it can't see the exact values being used in
> queries. Can you show us the details of the function?
Thanks for the response. Chris Ruprecht and I got into an off-list
conversation and b
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> I can't help but feel that, because functions wrap everything in a
> transaction, some sort of tinkering with the xlog settings/performance
> is called for ...
I kinda doubt it. More likely sources of trouble involve the optimizer
picking bad plans bec
Folks,
I have this function that adds 100-900 rows to a table and then unpdates
them 12 times using data pulled from all over the database. I've
increased the pgsql buffer, the sort memory, and wal_files significantly
(2048, 1024 and 16) as well as adding a few relevant indexes.
However, this f
