Re: Freeze avoidance of very large table.

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Freeze avoidance of very large table.
Date: 2015-04-23 15:52:20
Message-ID: 55391534.6090201@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/23/2015 06:38 PM, Bruce Momjian wrote:
> On Thu, Apr 23, 2015 at 10:42:59AM +0300, Heikki Linnakangas wrote:
>> On 04/22/2015 09:24 PM, Robert Haas wrote:
>>>> I would feel safer if we added a completely new "epoch" counter to the page
>>>>> header, instead of reusing LSNs. But as we all know, changing the page
>>>>> format is a problem for in-place upgrade, and takes some space too.
>>> Yeah. We have a serious need to reduce the size of our on-disk
>>> format. On a TPC-C-like workload Jan Wieck recently tested, our data
>>> set was 34% larger than another database at the beginning of the test,
>>> and 80% larger by the end of the test. And we did twice the disk
>>> writes. See "The Elephants in the Room.pdf" at
>>> https://sites.google.com/site/robertmhaas/presentations
>>
>> Meh. Adding an 8-byte header to every 8k block would add 0.1% to the
>> disk size. No doubt it would be nice to reduce our disk footprint,
>> but the page header is not the elephant in the room.
>
> Agreed. Are you saying we can't find a way to fit an 8-byte value into
> the existing page in a backward-compatible way?

I'm sure we can find a way. We've discussed ways to handle page format
updates in pg_upgrade before, and I don't want to get into that
discussion here, but it's not trivial.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-04-23 15:53:37 Re: Freeze avoidance of very large table.
Previous Message Bruce Momjian 2015-04-23 15:49:30 Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property?