Re: A question about pages. Still not clear

Поиск
Список
Период
Сортировка
От Guido Barosio
Тема Re: A question about pages. Still not clear
Дата
Msg-id f7f6b4c70601120707r25774f7fuf56b87267ccd5ee7@mail.gmail.com
обсуждение исходный текст
Ответ на A question about pages. Still not clear  (tmorelli@tmorelli.com.br)
Список 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 по дате отправления:

Предыдущее
От: "A. Kretschmer"
Дата:
Сообщение: Re: Forums
Следующее
От: Michael Fuhr
Дата:
Сообщение: Re: Removing duplicate entries