Re: Freeze avoidance of very large table.
От | Heikki Linnakangas |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | 55391534.6090201@iki.fi обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Freeze avoidance of very large table.
|
Список | 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
В списке pgsql-hackers по дате отправления: