Re: Performance optimization of btree binary search

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Performance optimization of btree binary search
Дата
Msg-id 52A07FA6.2070109@vmware.com
обсуждение исходный текст
Ответ на Re: Performance optimization of btree binary search  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Performance optimization of btree binary search
Список pgsql-hackers
On 12/05/2013 07:30 AM, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: logical changeset generation v6.7
Следующее
От: Andres Freund
Дата:
Сообщение: Re: shared memory message queues