From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, alvherre(at)commandprompt(dot)com, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_freespacemap question |
Date: | 2006-03-08 15:27:48 |
Message-ID: | 14469.1141831668@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>> Good points! I had not noticed this test case. Probably NULL is better
> Would setting it to 'BLCKSZ - (fixed index header stuff)' be better,
No, I don't think so, because that will just make it harder to recognize
what's what (remember that BLCKSZ isn't really a constant, and the index
overhead is not the same for all AMs either). The point here is that
for indexes the FSM tracks whole-page availability, not the amount of
free space within pages. So I think NULL is a reasonable representation
of that. Using NULL will make it easy to filter the results if you want
to see only heap-page data or only index-page data, whereas it will be
very hard to do that if the view adopts an ultimately-artificial
convention about the amount of available space on an index page.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2006-03-08 15:28:16 | Re: Merge algorithms for large numbers of "tapes" |
Previous Message | Tom Lane | 2006-03-08 15:21:04 | Re: Merge algorithms for large numbers of "tapes" |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2006-03-08 15:29:53 | Re: CREATE SYNONYM ... |
Previous Message | Jonah H. Harris | 2006-03-08 14:18:15 | Re: CREATE SYNONYM ... |