From: | Alexy Khrabrov <deliverable(at)gmail(dot)com> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Greg Smith" <gsmith(at)gregsmith(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: two memory-consuming postgres processes |
Date: | 2008-05-02 22:03:12 |
Message-ID: | C123A0EA-7B13-4297-9263-270224DF1F10@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On May 2, 2008, at 2:43 PM, Kevin Grittner wrote:
>>>> Alexy Khrabrov wrote:
>
>> SInce I don't index on that
>> new column, I'd assume my old indices would do -- do they change
>> because of rows deletions/insertions, with the effective new rows
>> addresses?
>
> Every update is a delete and insert. The new version of the row must
> be added to the index. Every access through the index then has to
> look at both versions of the row to see which one is "current" for its
> transaction. Vacuum will make the space used by the dead rows
> available for reuse, as well as removing the old index entries and
> making that space available for new index entries.
OK. I've cancelled all previous attempts at UPDATE and will now
create some derived tables. See no changes in the previous huge table
-- the added column was completely empty. Dropped it. Should I
vacuum just in case, or am I guaranteed not to have any extra rows
since no UPDATE actually went through and none are showing?
Cheers,
Alexy
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-02 22:20:58 | Re: Very slow INFORMATION_SCHEMA |
Previous Message | Kevin Grittner | 2008-05-02 21:43:58 | Re: two memory-consuming postgres processes |