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

On Tue, Jun 12, 2012 at 11:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Tue, Jun 12, 2012 at 7:42 AM, Robert Haas <robertmhaas(at)gmail(dot)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