On Oct 2, 2008, at 10:32 AM, Robert Treat wrote:
select pg_relation_size(tablename) from pg_tables;
since pg_tables is presented as a more user-friendly option to
something like
pg_class this might be something more widely used, plus we don't
have the
easy way out of just telling them to
Dave Page wrote:
On Tue, Sep 30, 2008 at 2:53 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Should pg_relation_indexes_size() include the FSMs of the indexes? Should
pg_relation_toast_size() include the toast index and FSM as well?
It might be worth revisiting the near identical discussions
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The FSM is not updated during WAL replay. That means that after crash
recovery, the FSM won't be completely up-to-date, but at roughly the
state it was at last checkpoint. In a warm stand-by, the FSM will
reflect the situation at last full
On Thu, Oct 2, 2008 at 8:56 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
It might be worth revisiting the near identical discussions we had
when Andreas I integrated this stuff into the backend for 8.1.
Good point. The previous discussions evolved to having two functions,
Le jeudi 02 octobre 2008, Heikki Linnakangas a écrit :
pg_relation_size('footable') for size of the main data fork
pg_relation_size('footable', 'fsm') for FSM size
As good as possible, if you ask me!
Regards,
--
dim
signature.asc
Description: This is a digitally signed message part.
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The FSM is not updated during WAL replay. That means that after crash
recovery, the FSM won't be completely up-to-date, but at roughly the
state it was at last checkpoint. In a warm stand-by, the FSM will
Heikki Linnakangas [EMAIL PROTECTED] writes:
Following that philosophy, I think the idea of adding a new optional
fork name argument to pg_relation_size() is the right thing to do:
pg_relation_size('footable') for size of the main data fork
pg_relation_size('footable', 'fsm') for FSM size
On Thursday 02 October 2008 08:37:59 Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Following that philosophy, I think the idea of adding a new optional
fork name argument to pg_relation_size() is the right thing to do:
pg_relation_size('footable') for size of the main data
Robert Treat wrote:
On Thursday 02 October 2008 08:37:59 Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
There's currently two variants of both pg_relation_size and
pg_total_relation_size, one takes an OID and one takes a relation name
as argument. Any objections to having just
I finally committed the new version of the FSM rewrite, after fixing the
latest round of Tom's comments. There's a few loose ends I'm going to
address as subsequent patches:
pg_relation_size() doesn't include the size of the FSM. Should it? I'm
thinking no, but pg_total_relation_size()
On Tue, Sep 30, 2008 at 4:32 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
pg_relation_size() doesn't include the size of the FSM. Should it? I'm
thinking no,
No
but pg_total_relation_size() should.
+1
The FSM is not updated during WAL replay. That means that after crash
Gurjeet Singh [EMAIL PROTECTED] writes:
I vote for contrib/pg_freespacemap functions to be included in the core
since FSM is in core.
The old FSM was in core, too. That's not a helpful argument.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hi,
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
On Tue, Sep 30, 2008 at 6:09 PM, Dimitri Fontaine [EMAIL PROTECTED]wrote:
Hi,
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
Dimitri Fontaine wrote:
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)
No, it
Heikki Linnakangas napsal(a):
The FSM is not updated during WAL replay. That means that after crash
recovery, the FSM won't be completely up-to-date, but at roughly the
state it was at last checkpoint. In a warm stand-by, the FSM will
reflect the situation at last full backup. We need to
Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
Dimitri Fontaine wrote:
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
Gurjeet Singh wrote:
On Tue, Sep 30, 2008 at 6:09 PM, Dimitri Fontaine [EMAIL PROTECTED]wrote:
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
Dimitri Fontaine wrote:
Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
Dimitri Fontaine wrote:
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
Dimitri Fontaine [EMAIL PROTECTED] writes:
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
Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
You forgot the toast size.
Yeah, pg_total_relation_size() - pg_relation_size() is not equal to the
total size of indexes because of that.
Oops. Thanks for pointing this to me...
But you can do SUM(pg_relation_size(index)) across all
Dimitri Fontaine wrote:
Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
You forgot the toast size.
Yeah, pg_total_relation_size() - pg_relation_size() is not equal to the
total size of indexes because of that.
Oops. Thanks for pointing this to me...
But you can do
On Tue, Sep 30, 2008 at 2:53 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
For convenience, would it be possible to see about having all this
provided by PostgreSQL?
a. pg_relation_size()
b. pg_relation_toast_size()
c. pg_relation_fsm_size()
d. pg_relation_indexes_size()
e.
On Tue, Sep 30, 2008 at 5:51 PM, Tom Lane [EMAIL PROTECTED] wrote:
Gurjeet Singh [EMAIL PROTECTED] writes:
I vote for contrib/pg_freespacemap functions to be included in the core
since FSM is in core.
The old FSM was in core, too. That's not a helpful argument.
In the absence of these
24 matches
Mail list logo
