Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id 55390735.1040508@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Freeze avoidance of very large table.  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On 4/23/15 2:42 AM, Heikki Linnakangas wrote:
> On 04/22/2015 09:24 PM, Robert Haas wrote:
>> 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.

I've often wondered if there was some way we could consolidate XMIN/XMAX 
from multiple tuples at the page level; that could be a big win for OLAP 
environments where most of your tuples belong to a pretty small range of 
XIDs. In many workloads you could have 80%+ of the tuples in a table 
having a single inserting XID.

Dunno how much it would help for OLTP though... :/
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Geoff Winkless
Дата:
Сообщение: Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
Следующее
От: Tom Lane
Дата:
Сообщение: Re: anole - test case sha2 fails on all branches