From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: jsonb contains behaviour weirdness |
Date: | 2014-09-15 18:29:54 |
Message-ID: | 1274.1410805794@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Personally I'd think that we should retain it for objects; Peter's
>> main argument against that was that the comment would be too complicated,
>> but that seems a bit silly from here.
> I just don't see any point to it. My argument against the complexity
> of explaining why the optimization is only used with objects is based
> on the costs and the benefits. I think the benefits are very close to
> nil.
It might be that the benefit is very close to nil; that would depend a lot
on workload, so it's hard to be sure. I'd say though that the cost is
also very close to nil, in the sense that we're considering two additional
compare-and-branch instructions in a function that will surely expend
hundreds or thousands of instructions if there's no such short-circuit.
I've certainly been on the side of "that optimization isn't worth its
keep" many times before, but I don't think the case is terribly clear cut
here. Since somebody (possibly you) thought it was worth having to begin
with, I'm inclined to follow that lead.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-09-15 18:40:49 | Re: jsonb contains behaviour weirdness |
Previous Message | Peter Geoghegan | 2014-09-15 18:25:41 | Re: B-Tree support function number 3 (strxfrm() optimization) |