Re: [HACKERS] compression in LO and other fields

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: [HACKERS] compression in LO and other fields
Дата
Msg-id 199911121342.WAA01906@ext04.sra.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] compression in LO and other fields  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] compression in LO and other fields  (Philip Warner <pjw@rhyme.com.au>)
Список pgsql-hackers
> > It sounds ideal but I remember that Vadim said inserting a 2GB record
> > is not good idea since it will be written into the log too. If it's a
> > necessary limitation from the point of view of WAL, we have to accept
> > it, I think.
> 
> LO won't make that any better: the data still goes into a table.
> You'd have 2GB worth of WAL entries either way.

What in my mind was LO that is not under the transaction control.  I
would not say this is a good thing, but I'm afraid we might need this
kind of beast in WAL.

> The only thing LO would do for you is divide the data into block-sized
> tuples, so there would be a bunch of little WAL entries instead of one
> big one.  But that'd probably be easy to duplicate too.  If we implement
> big tuples by chaining together disk-block-sized segments, which seems
> like the most likely approach, couldn't WAL log each segment as a
> separate log entry?  If so, there's almost no difference between LO and
> inline field for logging purposes.

Right.

BTW, does anybody know how BLOBs are handled by WAL in commercial
DBMSs?
---
Tatsuo Ishii


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

Предыдущее
От: Zeugswetter Andreas SEV
Дата:
Сообщение: AW: AW: [HACKERS] Re: [GENERAL] users in Postgresql
Следующее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] compression in LO and other fields