| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FSM search modes |
| Date: | 2009-09-18 06:09:15 |
| Message-ID: | 1253254155.9666.285.camel@ebony.2ndQuadrant |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2009-09-18 at 10:47 +0900, Itagaki Takahiro wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>
> > * compact - page selection specifically attempts to find the lowest
> > numbered blocks, so that the table will naturally shrink over time.
>
> We cannot shrink the table if one tuple remains at the end of table
> and the tuple is always HOT-updated, because we put a new tuple into
> the same page where the old tuple is placed if possible.
>
> In addition to your intelligent FSM search modes,
> do we need another algorithm to make the compaction to work better?
Perhaps we can have an additional piece of information about a table.
Something like target_size, so that normal updaters that attempt HOT
updates on blocks greater than target_size would know to avoid that
block and to seek a new location for the row lower in the table. Perhaps
such information could be reset and then sent via invalidation
mechanisms.
I'm thinking along the lines of a "fire alarm". An occasional mechanism
by which we can inform users of the need to evacuate certain blocks.
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2009-09-18 06:10:14 | Re: [PATCH] pgbench: new feature allowing to launch shell commands |
| Previous Message | Fujii Masao | 2009-09-18 05:50:06 | Re: Streaming Replication patch for CommitFest 2009-09 |