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

Re: [PATCHES] pg_freespacemap question

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: markir(at)paradise(dot)net(dot)nz, alvherre(at)commandprompt(dot)com, peter_e(at)gmx(dot)net, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] pg_freespacemap question
Date: 2006-03-13 03:15:07
Message-ID: 20130.1142219707@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> writes:
> That sounds strange to me. Each record of accounts tables is actually
> exactly same, i.e fixed size. So it should be possible that UPDATE
> reuses any free spaces made by previous UPDATE. If FSM neglects those
> free spaces "because they are uselessly small", then the unrecycled
> pages are getting grow even if they are regulary VACUUMed, no?

The point here is that if tuples require 50 bytes, and there are 20
bytes free on a page, pgstattuple counts 20 free bytes while FSM
ignores the page.  Recording that space in the FSM will not improve
matters, it'll just risk pushing out FSM records for pages that do
have useful amounts of free space.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Christopher Kings-LynneDate: 2006-03-13 03:29:44
Subject: Re: [PATCHES] pg_freespacemap question
Previous:From: Qingqing ZhouDate: 2006-03-13 03:02:34
Subject: Re: About Buffer Flushing Function

pgsql-patches by date

Next:From: Christopher Kings-LynneDate: 2006-03-13 03:29:44
Subject: Re: [PATCHES] pg_freespacemap question
Previous:From: Tatsuo IshiiDate: 2006-03-13 02:56:37
Subject: Re: [PATCHES] pg_freespacemap question

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