Re: A question about pages. Still not clear - Mailing list pgsql-novice

From Guido Barosio
Subject Re: A question about pages. Still not clear
Date
Msg-id f7f6b4c70601120707r25774f7fuf56b87267ccd5ee7@mail.gmail.com
Whole thread Raw
In response to A question about pages. Still not clear  (tmorelli@tmorelli.com.br)
List pgsql-novice
quote: And, finally, what does it mean: "contrib/pgstattuple/ " (from your last answer)
 
Means, check in the contrib/ directory in your pgsql source tree, for the pgstattuple stuff.
It's  extremely clear and may help you understanding some of your doubts.
 
Even more, you shall read the source of pgstattuple, and then call the program. That will give you a big idea.
 
(tho,...check the contrib entirely, you will get a brand new snap of usefull tools)
 
Best regards,
Guido.
 


 
On 1/12/06, tmorelli@tmorelli.com.br <tmorelli@tmorelli.com.br > wrote:
Tom,

I've done more tests. After re-creating a table with just one field
(char(8000)), I inserted 26 records. Look at this:

teste=# select relname, oid, relpages, reltuples from pg_class where oid >=
169982690;
        relname          |    oid    | relpages | reltuples
--------------------------+-----------+----------+-----------
pg_toast_169982690_index | 169982694 |        1 |         0
pg_toast_169982690       | 169982692 |        0 |         0
ix                       | 169982695 |        2 |        26
t                        | 169982690 |        1 |        26
(4 rows)

Every insert was like this:

insert into t values (repeat('a',8000));

Obviously, there must be some kind of compression (the toast table is empty!).
The main question is:

Is there any way of knowing exactly WHEN there will be a new page allocation?
Is it configurable? How could I inspect compression stuff?

VACUUM FULL VERBOSE did not make any difference.

And, finally, what does it mean: "contrib/pgstattuple/ " (from your last answer)

Best regards,

Eduardo Morelli

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster



--
"Adopting the position that you are smarter than an automaticoptimization algorithm is generally a good way to achieve lessperformance, not more" - Tom Lane.

pgsql-novice by date:

Previous
From: "A. Kretschmer"
Date:
Subject: Re: Forums
Next
From: Michael Fuhr
Date:
Subject: Re: Removing duplicate entries