Rosser Schwarz wrote:
> Greg Spiegelberg wrote:
>
>
>>I've been following this thread closely as I have the same problem
>>with an UPDATE. Everything is identical here right down to the
>>strace output.
>
>
>>Has anyone found a workaround or resolved the problem? If not,
>>I have test systems here which I can use to help up test and explore.
>
>
> I'm still gathering data. The explain analyze I'd expected to finish
> Thursday afternoon hasn't yet. I'm going to kill it and try a few
> smaller runs, increasing in size, until the behavior manifests.
>
> Will advise.
I've replaced my atrocious UPDATE with the following.
begin;
-- Drop all contraints
alter table ORIG drop constraint ...;
-- Drop all indexes
drop index ...;
-- Update
update ORIG set column=... where...;
commit;
Problem is when I recreate the indexes and add the constraints back
on ORIG I end up with the same long running process. The original
UPDATE runs for about 30 minutes on a table of 400,000 with the
WHERE matching about 70% of the rows. The above runs for about 2
minutes without adding the constraints or indexes however adding the
constraints and creating the dropped indexes negates any gain.
RedHat 7.3 + Kernel 2.4.24 + ext3 + PostgreSQL 7.3.5
Dual PIII 1.3'ishGHz, 2GB Memory
U160 OS drives and a 1Gbps test SAN on a Hitachi 9910
Greg
--
Greg Spiegelberg
Sr. Product Development Engineer
Cranel, Incorporated.
Phone: 614.318.4314
Fax: 614.431.8388
Email: gspiegelberg@Cranel.com
Cranel. Technology. Integrity. Focus.