Re: pg_total_relation_size() and CHECKPOINT

From: "Zubkovsky, Sergey" <Sergey(dot)Zubkovsky(at)transas(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-docs(at)postgresql(dot)org>
Subject: Re: pg_total_relation_size() and CHECKPOINT
Date: 2008-03-14 15:23:22
Message-ID: 528853D3C5ED2C4AA8990B504BA7FB850106DF13@sol.transas.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

Hi,

Here is my example.

We are creating 2 tables:

create table t1 ( a int, b varchar( 30 ) );

create table t1_arh ( c text );

and filling 't1':

insert into t1 select generate_series(1, 100000 ), generate_series(1,
100000 );

The "arch_table_sp" user-function will be used for extracting data from
't1' and archiving it to 't1_arh'.

CREATE OR REPLACE FUNCTION "arch_table_sp" ( tblName name, arcTblName
name )

RETURNS void

AS $BODY$

DECLARE

fn text;

chunk CONSTANT bigint := 512*1024;

off bigint := 0;

rdBytes bigint;

buf text;

BEGIN

SELECT setting INTO STRICT fn FROM pg_settings WHERE name =
'data_directory';

fn := fn || '/tbldata.txt';

PERFORM pg_file_unlink( fn );

EXECUTE 'COPY ( SELECT * FROM ' || quote_ident( tblName ) || ' ) TO
' || quote_literal( fn );

EXECUTE '

CREATE OR REPLACE FUNCTION "__InsertChunk__sp" ( data text )

RETURNS void AS

$_$

INSERT INTO ' || quote_ident( arcTblName ) || ' ( c ) VALUES ( $1 );

$_$

LANGUAGE sql;';

LOOP

buf := pg_file_read( fn, off, chunk );

rdBytes := length( buf );

IF ( rdBytes > 0 ) THEN

PERFORM "__InsertChunk__sp"( buf );

off := off + rdBytes;

END IF;

EXIT WHEN ( rdBytes <> chunk );

END LOOP;

PERFORM pg_file_unlink( fn );

END;

$BODY$ LANGUAGE plpgsql;

Now we are executing the following statements in one transaction:

select "arch_table_sp"( 't1', 't1_arh' );

select pg_total_relation_size( 't1_arh' );

The result is 417792 (in the general case it may be another value, for
example, I received 303104, 573440 and etc).

If we are executing these statements in separate transactions with a
couple of seconds between them than we have received another value:

truncate table t1_arh;

select "arch_table_sp"( 't1', 't1_arh' );

select pg_total_relation_size( 't1_arh' );

The result is 688128!

With explicit CHECKPOINT we will have one more value:

truncate table t1_arh;

select "arch_table_sp"( 't1', 't1_arh' );

CHECKPOINT;

select pg_total_relation_size( 't1_arh' );

The result is 696320!

It would be interesting why we have such results...

It's obviously that CHECKPOINT is not a good decision.

Can you suggest some other approach instead of explicit CHECKPOINT?

Sorry for my English.

I hope this example is quite clear.

Thanks in advance,

Zubkovsky Sergey

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Thursday, March 13, 2008 11:21 PM
To: Zubkovsky, Sergey
Cc: pgsql-docs(at)postgresql(dot)org
Subject: Re: [DOCS] pg_total_relation_size() and CHECKPOINT

"Zubkovsky, Sergey" <Sergey(dot)Zubkovsky(at)transas(dot)com> writes:

> I've detected that a result value of pg_total_relation_size() for an

> actively updated table might be significantly differ from a result
that

> is returned after explicit CHECKPOINT command execution.

Uh, can you show a specific example of what you mean?

> I understand the reasons of such behavior: cache buffers must be
flushed

> in order to be sure that pg_total_relation_size() result will be like
we

> expect.

I wouldn't think so. The space for a page is allocated immediately when

needed --- its *contents* might not be up to date, but that shouldn't

affect pg_total_relation_size.

regards, tom lane

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2008-03-14 16:19:20 Re: pg_total_relation_size() and CHECKPOINT
Previous Message Tom Lane 2008-03-13 20:20:30 Re: pg_total_relation_size() and CHECKPOINT

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-03-14 16:04:09 Re: PROC_VACUUM_FOR_WRAPAROUND doesn't work expectedly
Previous Message Chris Browne 2008-03-14 14:55:49 Re: Data Recovery feature