From: | Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr> |
---|---|
To: | Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> |
Cc: | "jd(at)commandprompt(dot)com" <jd(at)commandprompt(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: SELECT INTO large FKyed table is slow |
Date: | 2010-12-01 17:00:26 |
Message-ID: | 4CF67F2A.4070703@megafon.hr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 12/01/2010 05:34 PM, Mladen Gogala wrote:
> Mario Splivalo wrote:
>>
>>
>> Yes, as Mladen Gogala had advised. No noticable change in performance -
>> it's still slow :)
>>
>
> Declaring constraints as deferrable doesn't do anything as such, you
> have to actually set the constraints deferred to have an effect. You
> have to do it within a transaction block. If done outside of the
> transaction block, there is no effect:
I understand, I did as you suggested.
Begin; Set constraints all deferred; select my_insert_drones_function();
commit
> I was able to insert the same value twice, it only failed at the end of
> the transaction.
>> But, just for the sake of clarification - I tought that DEFERRABLE would
>> matter if I do a lot of INSERTs, inside a FOR loop or something like
>> that. Since I'm doing INSERT INTO ... SELECT, does it makes any difference?
>>
> You cannot tell which part takes a long time, select or insert, without
> profiling. I certainly cannot do it over the internet.
If I first select to a dummy temprary table, that SELECT is fast. Just
INSERT INTO SELECT is slow.
I'll try what Pierre suggested, on whole new filesystem. This one did
get quite filled with thousands of files that I deleted while the
database was working.
Mario
From | Date | Subject | |
---|---|---|---|
Next Message | Mladen Gogala | 2010-12-01 17:06:35 | Re: Clarification, please |
Previous Message | Richard Broersma | 2010-12-01 16:57:01 | Re: Clarification, please |