Re: SELECT INTO large FKyed table is slow

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

In response to

Responses

Browse pgsql-performance by date

  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