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*
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 i
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 data.
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 pus
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 d
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 sp
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 sma
> > 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
> >>
> >>
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 identic
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 t
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,
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 ind
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 (reme
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 i
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 t
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
> > 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!
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.
Righ
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
-+-+---+-
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 co
> 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
> > -+-+---+
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
> -+-+---+-++---
Hi,
I tried pg_freespacemap and found strange result:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
-+-+---+-++
25 matches
Mail list logo
