Re: Block-level CRC checks
От | Greg Stark |
---|---|
Тема | Re: Block-level CRC checks |
Дата | |
Msg-id | 1F996909-8508-4F91-B44C-8B07F9FB68F7@mit.edu обсуждение исходный текст |
Ответ на | Re: Block-level CRC checks (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
It can save space because the line pointers have less alignment requirements. But I don't see any point in the current state. -- Greg On 2009-12-04, at 3:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg Stark <gsstark@mit.edu> writes: >> I'm not sure why I said "including ctid". We would have to move >> everything transactional to the line pointer, including xmin, xmax, >> ctid, all the hint bits, the updated flags, hot flags, etc. The only >> things left in the tuple header would be things that have to be there >> such as HAS_OIDS, HAS_NULLS, natts, hoff, etc. It would be a pretty >> drastic change, though a fairly logical one. I recall someone >> actually >> submitted a patch to separate out the transactional bits anyways a >> while back, just to save a few bytes in in-memory tuples. If we could >> save on disk-space usage it would be a lot more compelling. But it >> doesn't look to me like it really saves enough often enough to be >> worth so much code churn. > > It would also break things for indexes, which don't need all that > stuff > in their line pointers. > > More to the point, moving the same bits to someplace else on the page > doesn't save anything at all. > > regards, tom lane
В списке pgsql-hackers по дате отправления: