| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
| Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: HOT patch - version 15 |
| Date: | 2007-09-06 19:20:44 |
| Message-ID: | 893.1189106444@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Alvaro Herrera wrote:
>> That would be best, if at all possible. You can prune without accessing
>> anything outside the page itself, right?
> Yes, though you do need to have an oldest xmin to determine which tuples
> are dead, and the removed tuples need to be WAL-logged.
Hmm ... also check commit status (pg_clog access). I've always thought
that those things couldn't be done in bgwriter, because it wasn't
running real transactions, but right at the moment I can't see that
there is any obstacle. Perhaps that meme dates from a time when
GetOldestXmin didn't work outside a transaction?
Pushing the prune/defrag work into bgwriter would certainly fix my
worries about having it in foreground query paths.
(And screw up all Greg Smith's work on how much bgwriter should run...
or maybe this should be a third independent task within bgwriter?)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-09-06 19:32:07 | Re: HOT patch - version 15 |
| Previous Message | Alvaro Herrera | 2007-09-06 19:11:42 | Re: HOT patch - version 15 |