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.

-- Drop all contraints
alter table ORIG drop constraint ...;
-- Drop all indexes
drop index ...;
-- Update
update ORIG set column=... where...;

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 Spiegelberg
 Sr. Product Development Engineer
 Cranel, Incorporated.
 Phone: 614.318.4314
 Fax:   614.431.8388
Cranel. Technology. Integrity. Focus.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match

Reply via email to