On Tue, Jun 12, 2012 at 12:41 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>> -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.
I don't think it's going to solve the problem in general, but TBH I
don't think Jeff's proposal is, either. I mean, ignoring
xmin-committed, xmax-committed, and all-visible bits is going to come
with a pretty steep performance penalty all of its own. I don't doubt
that you can construct situations in which it's better than incurring
the I/O associated with setting those bits after the fact, but I also
don't doubt that the reverse is true. Furthermore, any system that
involves sometimes ignoring those things is going to add cost in
extremely hot code paths even when the user doesn't elect to take
advantage of the new feature.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
