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

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: 9.3: load path to mitigate load penalty for checksums
Дата
Msg-id CAHyXU0wXeL008MUGmOdv82bapqk+Wj+q1vbX=a4nY=2aamSb4w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.3: load path to mitigate load penalty for checksums  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 9.3: load path to mitigate load penalty for checksums  (Greg Stark <stark@mit.edu>)
Re: 9.3: load path to mitigate load penalty for checksums  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Jun 12, 2012 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Tue, Jun 12, 2012 at 7:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Instead of trying to maintain MVCC semantics, maybe we should just
>>> have something like COPY (FROZEN) that just writes frozen tuples into
>>> the table and throws MVCC out the window.  Seems like that would be a
>>> lot easier to implement and satisfy basically the same use cases.
>
>> -1: The situation with hint bit i/o patterns on many workloads is
>> untenable but it's not safe to assume MVCC can be ditched in those
>> workloads.  Also, COPY does nothing about deletes.  Neither does the
>> proposal as stated but I think it's easier to generalize into 'I want
>> to put hint bits in now so I don't have to deal with them later'.
>
> Dunno, I think Robert's idea has a fair amount of merit: mainly because
> it will probably satisfy 90% of use cases for 1% of the work.

90%?  Hint bits i/o issues are not limited to bulk loads.   They apply
to all many-record-per-transaction DML including (and especially)
deletes.  Also it's not safe to assume that insertion heavy clients
can be migrated to COPY.  For example, JDBC bulk loading AFAIK does
not use COPY and even if it did wouldn't be able to decorate the
command for a long time for most production workloads.

Vs Jeff's proposal you have a point -- I'm just very skeptical it's
going to do enough to mitigate the performance hit.

merlin


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Следующее
От: Robert Haas
Дата:
Сообщение: Re: /proc/self/oom_adj is deprecated in newer Linux kernels