Re: 9.3: load path to mitigate load penalty for checksums

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: 9.3: load path to mitigate load penalty for checksums
Дата
Msg-id CA+TgmoaSVH8jWPgKB8zxcAvH=7v2wLG1AfKiHNBi1Ae5JHFc8A@mail.gmail.com
обсуждение исходный текст
Ответ на 9.3: load path to mitigate load penalty for checksums  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: 9.3: load path to mitigate load penalty for checksums  (Noah Misch <noah@leadboat.com>)
Re: 9.3: load path to mitigate load penalty for checksums  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On Mon, Jun 4, 2012 at 9:26 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> Thoughts?

Simon already proposed a way of doing this that doesn't require
explicit user action, which seems preferable to a method that does
require explicit user action, even though it's a little harder to
implement.  His idea was to store the XID of the process creating the
table in the pg_class row, which I think is *probably* better than
your idea of having a process that waits and then flips the flag.
There are some finicky details though - see previous thread for
discussion of some of the issues.

It would be very nice to have a method that detects whether or not
there is only one open snapshot in a particular backend.  Any time
that condition is met, tuples written into a table created or
truncated in the current transaction can be written with
HEAP_XMIN_COMMITTED already set.  That is not as nice as being able to
set HEAP_XMIN_COMMITTED *and* PD_ALL_VISIBLE *and* the visibility map,
but it would still be a big improvement over the status quo.  I would
like to see us get that part done and committed and then worry about
writing the tuples with PD_ALL_VISIBLE set as a separate project.  In
many cases it would also be nice to write the tuples pre-frozen, so I
think we should look for a design that will support that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: "page is not marked all-visible" warning in regression tests
Следующее
От: Tom Lane
Дата:
Сообщение: Avoiding adjacent checkpoint records