From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clarification of action on Delete |
Date: | 2004-09-09 22:10:23 |
Message-ID: | 11108.1094767823@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
>> Tom Lane wrote
>> It would be nice to push the TOAST deletions off to become the
>> responsibility of VACUUM, but I'm not entirely sure how to do that
>> without giving up the UPDATE optimization of shared values.
> That could be optimised, but there are advantages to removing TOASTed values
> immediately since they are potentially big space hogs, so I'm actually glad
> to hear that it works that way.
Well, they certainly aren't going to be *removed* immediately; we
couldn't roll back the deletion if we did. The physical removal
will happen during VACUUM, same as for ordinary table rows. So there's
not really any functional reason why we couldn't have VACUUM do the
marking for removal too, except that it does not know when looking at
the deleted table row whether the toast entries are shared with other
versions of the row.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2004-09-09 22:11:22 | Re: Clarification of action on Delete |
Previous Message | Greg Sabino Mullane | 2004-09-09 22:08:23 | Re: psql questions: SQL, progname, copyright dates |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2004-09-09 22:11:22 | Re: Clarification of action on Delete |
Previous Message | Tom Lane | 2004-09-09 21:49:44 | Re: Clarification of action on Delete |