Re: How many insert + update should one transaction handle?

From: Ben-Nes Yonatan <nimrod(at)canaan(dot)co(dot)il>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Yonatan Ben-Nes <da(at)canaan(dot)co(dot)il>, Gnanavel S <s(dot)gnanavel(at)gmail(dot)com>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Dawid Kuroczko <qnex42(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, bruno(at)wolff(dot)to, smarlowe(at)g2switchworks(dot)com
Subject: Re: How many insert + update should one transaction handle?
Date: 2005-10-02 08:55:32
Message-ID: 433FA084.2060202@canaan.co.il
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jim C. Nasby wrote:

>On Tue, Sep 27, 2005 at 01:34:37PM +0200, Yonatan Ben-Nes wrote:
>
>
>>>Based on http://lnk.nu/developer.postgresql.org/44b.c, line 1478 on,
>>>there's not a lot that happens during the ALTER TABLE. Likewise DROP
>>>(line 517) doesn't do much either. So basically, anything trying to
>>>access the old table will block for a while waiting for the update to
>>>happen.
>>>
>>>But keep in mind that 'a while' will depend on what's happening on the
>>>system. Imagine...
>>>
>>>Start long transaction involving table
>>>Run code above; drop aquires lock on table
>>>
>>>Everything else against table will now block, waiting for the DROP to
>>>happen.
>>>
>>>
>>Jim unless I didnt understand you I think that at my case I wont need to
>>make any long transaction which will handle the DROP & renaming of tables.
>>I will actually have 2 transactions now:
>>1. which will handle the INSERT + UPDATE of the data into the temp_table
>>& at the end will move all of the new data (without the deleted tuples)
>>to the new_table and create its indexes.
>>2. the second transaction will only handle the drop & renaming of the 2
>>tables (new_table & table);
>>
>>The question is whats the expected time for the second transaction to
>>run? will it create problems to the constant availability of the site?
>>
>>S.Gnanavel I tried your idea but sadly it gives me the same block as I
>>would DROP the table and not RENAME it.
>>
>>
>
>Like I said, neither the ALTER or the DROP do much themselves. There is
>a slight advantage to Gnanavel's plan in that the ALTER won't wait for
>the filesystem to delete the files from the disk, but I *think* that
>DROP will. So it will be slightly faster.
>
>In either case, if a user is running a long transaction on the old table
>when you try and rename/drop it, that is going to completely swamp the
>effects of everything else. So, if you have some long-running queries
>that use that table, there is going to be a noticable delay to the
>system. If you don't have any queries like that, then this should work
>just fine.
>
>

Thanks for the help, now ill just have to think what will be better at
my case.

Shana Tova Everyone! (Happy new year in hebrew :))
Ben-Nes Yonatan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Zlatko Matić 2005-10-02 09:37:10 varchar to text
Previous Message Cosmopo 2005-10-02 04:37:49 Multiple database queries