Skip site navigation (1) Skip section navigation (2)

Re: FSM rewrite committed, loose ends

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Subject: Re: FSM rewrite committed, loose ends
Date: 2008-09-30 12:39:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
> pg_relation_size() doesn't include the size of the FSM. Should it? I'm
> thinking "no", but pg_total_relation_size() should.

What's practical about pg_relation_size() and pg_total_relation_size() as of 
8.3 is that the diff is the cumulated indexes storage volume. Your proposal 
makes it harder to get this information, but sounds good otherwise.
Would it be possible to add in some new APIs to?
 a. pg_relation_size()
 b. pg_relation_fsm_size()
 c. pg_relation_indexes_size()
 d. pg_total_relation_size() = a + b + c

This scheme will need new functions for each new kind of forks, but I think 
it's a good idea for the user to be able to know which fork is responsible 
for what on-disk volume.

> VACUUM VERBOSE output no longer prints the number of pages with "usable
> free space", because we no longer track such a value during the vacuum.
> You can use contrib/pg_freespacemap to view the contents of the FSM in
> detail, but should VACUUM VERBOSE still print something about the amount
> of free space on the relation? Perhaps the total amount of free space in
> the relation?

What about another function to get just this information?
 e. pg_relation_free_space()

Question for the slow readers: this new FSM scheme being dynamic, it's no 
longer possible to have table bloat, right?
(where table bloat is full of dead-for-any-transaction tuples, and you have to 
CLUSTER or VACUUM FULL to be able to reuse the space it takes)

Regards, keep up the good (team) work :)

In response to


pgsql-hackers by date

Next:From: Gurjeet SinghDate: 2008-09-30 12:45:37
Subject: Re: FSM rewrite committed, loose ends
Previous:From: Tom LaneDate: 2008-09-30 12:21:17
Subject: Re: FSM rewrite committed, loose ends

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group