Hmm, so it is some kind of file / table locking issue, not general IO
system malfunction.
It would be interesting and useful to run this use case on other
postgres instance (or several instances), including non-Windows ones.
OTOH Pg on Windows housekeeping was always "fun" - I advise all my
clien
Thanks a lot you saved my day
create temp table foo AS SELECT DISTINCT ...
did take a mere 77464.744 ms
And an additional
Insert into LPP select * from foo;
Just 576.909 ms
I don't really understand why it's working via a temp table but not
directly (or in any reasonable amount of time) - but at
Lutz Fischer writes:
> I have currently some trouble with inserts into a table
> If I run only [ the select part ]
> it returns 200620 rows in 170649 ms ( thats just under 3 minutes). I
> stopped the actual insert after about 8h.
It should not take 8h to insert 200k rows on any machine made thi
Just an idea - how long does it take to run _only_
CREATE TEMP TABLE foo AS
On Thu, Dec 13, 2012 at 4:37 PM, Lutz Fischer
wrote:
> Hi
>
> I have currently some trouble with inserts into a table
>
> INSERT INTO LPP (PPID, LID)
> SELECT DISTINCT PPid, LID FROM
> (SELECT * FROM PP WHERE
I would strongly discourage you from droppping the referential integrity. You
risk data corruption, which will cost you a good deal of time to sort it out
properly, and corruption prevents you to apply the R.I. again. Also it has
hardly any performance impact.
Are the plans different? ( i gue
