On 01/14/2014 11:22 PM, Peter Geoghegan wrote:
On Tue, Jan 14, 2014 at 2:43 AM, Heikki Linnakangas
<hlinnakan...@vmware.com> wrote:
You have suspected that many times throughout this thread, and every time
there's been a relatively simple solutions to the issues you've raised. I
suspect that's also going to be true for whatever mundane next issue you
come up with.
I don't think it's a mundane issue. But in any case, you haven't
addressed why you think your proposal is more or less better than my
proposal, which is the pertinent question.
1. It's simpler.
2. Works for exclusion constraints.
You haven't given me so
much as a high level summary of whatever misgivings you may have about
it, even though I've asked you to comment on my approach to value
locking several times. You haven't pointed out that it has any
specific bug (which is not to suppose that that's because there are
none). The point is that it is not my contention that what you're
proposing is totally unworkable. Rather, I think that the original
proposal will probably ultimately perform better in all cases, is
easier to reason about and is certainly far more modular. It appears
to me to be the more conservative of the two proposals. In all
sincerity, I simply don't know what factors you're weighing here. In
saying that, I really don't mean to imply that you're assigning weight
to things in a way that I am in disagreement with. I simply don't
understand what is important to you here, and why your proposal
preserves or enhances the things that you believe are important. Would
you please explain your position along those lines?
I guess that simplicity is in the eye of the beholder, but please take a
look at git diff --stat:
41 files changed, 1224 insertions(+), 107 deletions(-)
vs.
50 files changed, 2215 insertions(+), 240 deletions(-)
Admittedly, some of the difference comes from the fact that you've spent
a lot more time commenting and polishing the btreelock patch. But mostly
I dislike additional complexity required in b-tree for this.
I don't think B-tree locking is more conservative. The
insert-and-then-check approach is already used by exclusion constraints,
I'm just extending it to not abort on conflict, but do something else.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
