Patch applied. Thanks.
---
Mark Kirkwood wrote:
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Good points! I had not noticed this test case. Probably NULL is better
Would setting it to 'BLCKSZ -
Patch applied. Thanks.
---
Mark Kirkwood wrote:
Mark Kirkwood wrote:
Tom Lane wrote:
I do notice a rather serious shortcoming of pg_freespacemap in its
current incarnation, which is that it *only* shows you
Mark Kirkwood wrote:
Tom Lane wrote:
I do notice a rather serious shortcoming of pg_freespacemap in its
current incarnation, which is that it *only* shows you the per-page free
space data, and not any of the information that would let you determine
what the FSM is doing to filter the raw
Mark Kirkwood wrote:
Christopher Kings-Lynne wrote:
The point here is that if tuples require 50 bytes, and there are 20
bytes free on a page, pgstattuple counts 20 free bytes while FSM
ignores the page. Recording that space in the FSM will not improve
matters, it'll just risk pushing out FSM
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
I would have
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
No, because (a)
Tom Lane wrote:
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
vacuum/fsm
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
No,
Tatsuo Ishii [EMAIL PROTECTED] writes:
That sounds strange to me. Each record of accounts tables is actually
exactly same, i.e fixed size. So it should be possible that UPDATE
reuses any free spaces made by previous UPDATE. If FSM neglects those
free spaces because they are uselessly small,
The point here is that if tuples require 50 bytes, and there are 20
bytes free on a page, pgstattuple counts 20 free bytes while FSM
ignores the page. Recording that space in the FSM will not improve
matters, it'll just risk pushing out FSM records for pages that do
have useful amounts of free
Christopher Kings-Lynne wrote:
The point here is that if tuples require 50 bytes, and there are 20
bytes free on a page, pgstattuple counts 20 free bytes while FSM
ignores the page. Recording that space in the FSM will not improve
matters, it'll just risk pushing out FSM records for pages that
Mark,
I have tried your patches and it worked great. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Good points! I had not noticed this test case. Probably NULL is better
Would setting it to 'BLCKSZ - (fixed index header stuff)'
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Mark Kirkwood [EMAIL PROTECTED] 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
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] 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
Hi,
I tried pg_freespacemap and found strange result:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
-+-+---+-++
Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
-+-+---+-++
Peter Eisentraut wrote:
Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
Peter Eisentraut wrote:
Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
Tatsuo Ishii [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I have another question -- why is the view showing relfilenode and
reltablespace? I imagine it should be showing the relation Oid instead.
I guess that's because FSM keeps those info, not relation oid.
Right, which is correct
Tatsuo Ishii wrote:
Peter Eisentraut wrote:
Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I have another question -- why is the view showing relfilenode and
reltablespace? I imagine it should be showing the relation Oid instead.
I guess that's because FSM keeps those info, not relation oid.
BTW, I found the answer to my question myself by reading the source
code: if that's an index, then blockfreebytes is explicitly set to 0.
I suggest that this should be noted in the README and in this case
blockfreebytes is better to set to NULL, rather than 0.
Good points! I had not
Tatsuo Ishii wrote:
Just for curiousity, why FSM gathers info for indexes? I thought FSM
is only good for tables.
It's part of the implementation of the page-recycling algorithm for
btrees Tom did for 7.4. When a btree page is empty after a vacuum, it's
entered in the free space map. When a
Mark Kirkwood wrote:
Tatsuo Ishii wrote:
BTW, I found the answer to my question myself by reading the source
code: if that's an index, then blockfreebytes is explicitly set to 0.
I suggest that this should be noted in the README and in this case
blockfreebytes is better to set to NULL, rather
25 matches
Mail list logo
