Re: Placing hints in line pointers

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Placing hints in line pointers
Дата
Msg-id 1370832238.7746.11.camel@jdavis
обсуждение исходный текст
Ответ на Placing hints in line pointers  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Placing hints in line pointers  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
On Sat, 2013-06-01 at 15:45 +0100, Simon Riggs wrote:
> Doing this would have two purposes:
> 
> * We wouldn't need to follow the pointer if the row is marked aborted.
> This would save a random memory access for that tuple

That's quite similar to LP_DEAD, right? You could potentially set this
new hint sooner, which may be an advantage.

> We wouldn't need to do a FPW when a hint changes, we would only need
> to take a copy of the ItemId array, which is much smaller. And it
> could be protected by its own checksum.

I like the direction of this idea.

I don't see exactly how you want to make this safe, though. During
replay, we can't just replace the ItemId array, because the other
contents on the page might be newer (e.g. some tuples may have been
cleaned out, leaving the item pointers pointing to the wrong place).

> (In addition, if we wanted, this could be used to extend block size to
> 64kB if we used 8-byte alignment for tuples)

I think that supporting 64KB blocks has merit.

Interesting observation about the extra bits available. That would be an
on-disk format change, so perhaps this is something to add to the list
of "waiting for a format change"?

Regards,Jeff Davis





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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: pg_dump with postgis extension dumps rules separately
Следующее
От: Jeff Davis
Дата:
Сообщение: pg_filedump 9.3: checksums (and a few other fixes)