| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Unhappy about API changes in the no-fsm-for-small-rels patch |
| Date: | 2019-04-23 17:31:25 |
| Message-ID: | 29729.1556040685@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-04-23 15:46:17 +0530, Amit Kapila wrote:
>> If we invalidate it only when there's no space on the page, then when
>> should we set it back to available, because if we don't do that, then
>> we might miss the space due to concurrent deletes.
> Well, deletes don't traditionally (i.e. with an actual FSM) mark free
> space as available (for heap). I think RecordPageWithFreeSpace() should
> issue a invalidation if there's no FSM, and the block goes from full to
> empty (as there's no half-full IIUC).
Why wouldn't we implement this just as a mini four-entry FSM stored in
the relcache, and update the entries according to the same rules we'd
use for regular FSM entries?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shawn Debnath | 2019-04-23 17:34:59 | Re: POC: Cleaning up orphaned files using undo logs |
| Previous Message | Fabien COELHO | 2019-04-23 17:30:38 | Re: Trouble with FETCH_COUNT and combined queries in psql |