Re: Performance optimization of btree binary search

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Performance optimization of btree binary search
Date: 2013-12-05 13:29:10
Message-ID: 52A07FA6.2070109@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/05/2013 07:30 AM, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On Wed, 2013-12-04 at 20:27 -0500, Tom Lane wrote:
>>> Lazy people? I'm not in a hurry to drop it; it's not costing us much to
>>> just sit there, other than in this connection which we see how to fix.
>
>> Actually, I think it probably costs a fair portion of extension authors
>> when their initial code crashes because they forgot to declare all their
>> functions V1. I think it might actually be more of a bother to lazy
>> people than a benefit.
>
> Hm. We have heard one or two complaints like that, but not a huge number.

It happens to me about 75% of the time when I write a new C function.
These days, I usually realize it pretty quickly.

I wonder how easy it would be to make the compiler produce a warning
about it. Or issue a warning in PostgreSQL when you do CREATE FUNCTION
and the C function appears to be a V0 function.

> I'm worried about breaking code that's been working since god-knows-when;
> but I will concede there's little evidence that there's very much of that
> out there either.

I wouldn't mind just dropping the V0 support. It's not difficult to
modify your function for V1 convention, so if there's still anyone out
there using V0, it wouldn't be unreasonable to require them to update.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-12-05 13:29:31 Re: shared memory message queues
Previous Message Kyotaro HORIGUCHI 2013-12-05 13:03:51 Re: logical changeset generation v6.7