Re: Long running update

Поиск
Список
Период
Сортировка
От Andrew Janian
Тема Re: Long running update
Дата
Msg-id 80AD4CD06F9D904EAB15D6A1792268D53336A0@EXCHSTL2.scottrade.com
обсуждение исходный текст
Ответ на Long running update  ("Andrew Janian" <ajanian@scottrade.com>)
Ответы Re: Long running update  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
The actual table that I am updating is 134GB of the 135GB.  Each row has
one foreign key to another table, but no tables have a foreign key to
this table.

If I cancel the update then I can drop the new column, rename the old
column, do a vacuum, and then I should be left with what I started with,
right?

How can I expand that column without using this query?

I am using PostgreSQL 7.4.5.

Thanks for the help,

Andrew

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Sunday, October 16, 2005 12:07 PM
To: Andrew Janian
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Long running update

"Andrew Janian" <ajanian@scottrade.com> writes:
> I needed to expand the size of one of the varchar columns in a table
of
> my 135GB database.

How big is the particular table you are doing this on?  What foreign key
relationships is it involved in?  (I wonder if the time is going into FK
checking more than the actual update...)  What PG version exactly?

Personally, at this point I'd cancel the update while there's still time
to do a VACUUM before you have to be operational again.  You could do
the required operation (increasing a varchar's limit) in O(1) time by
twiddling the system catalogs.  You're going to need a VACUUM anyway
because of all the dead tuple versions left behind by the UPDATE.

            regards, tom lane



В списке pgsql-general по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: unsigned types
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: PostgreSQL Gotchas