Re: Page Checksums

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Page Checksums
Дата
Msg-id CA+U5nM+tVtyEXX6yhiNyMaX9YuUEyMow5ueFAkCzTGRriWaPBA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Page Checksums  (Robert Treat <rob@xzilla.net>)
Ответы Re: Page Checksums  (Jim Nasby <jim@nasby.net>)
Список pgsql-hackers
On Tue, Jan 24, 2012 at 2:49 PM, Robert Treat <rob@xzilla.net> wrote:
>> And yes, I would for sure turn such functionality on if it were present.
>>
>
> That's nice to say, but most people aren't willing to take a 50%
> performance hit. Not saying what we end up with will be that bad, but
> I've seen people get upset about performance hits much lower than
> that.

When we talk about a 50% hit, are we discussing (1) checksums that are
checked on each I/O, or (2) checksums that are checked each time we
re-pin a shared buffer?  The 50% hit was my estimate of (2) and has
not yet been measured, so shouldn't be used unqualified when
discussing checksums. Same thing is also true "I would use it"
comments, since we're not sure whether you're voting for (1) or (2).

As to whether people will actually use (1), I have no clue. But I do
know is that many people request that feature, including people that
run heavy duty Postgres production systems and who also know about
filesystems. Do people need (2)? It's easy enough to add as an option,
once we have (1) and there is real interest.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Removing freelist (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Multithread Query Planner