[HACKERS] 答复: [HACKERS] 答复: GiST API Adancement

Поиск
Список
Период
Сортировка
От Yuan Dong
Тема [HACKERS] 答复: [HACKERS] 答复: GiST API Adancement
Дата
Msg-id PS1PR03MB1755C229C8C352061B8B1C10AAC60@PS1PR03MB1755.apcprd03.prod.outlook.com
обсуждение исходный текст
Ответ на [HACKERS] Re: [HACKERS] 答复: GiST API Adancement  (Andrew Borodin <borodin@octonica.com>)
Список pgsql-hackers

2017-06-16 17:06 GMT+03:00 Tom Lane <tgl@sss.pgh.pa.us>:
> Yuan Dong <Doffery@hotmail.com> writes:
>> ·¢¼þÈË: Andrew Borodin <borodin@octonica.com>
>>> I think there is one more aspect of development: backward
>>> compatibility: it's impossible to update all existing extensions. This
>>> is not that major feature to ignore them.
>
>> I should still maintain original API of GiST after modification.
>
> To put a little context on that: we have always felt that it's okay
> to require extension authors to make small adjustments when going to
> a new major release.


Tom's comment is very helpful, I will keep it in mind.


>Then maybe it worth to consider more general API advancement at once?
>Here's my wish list:
>1. Choose subtree function as an alternative for penalty
>2. Bulk load support
>3. Better split framework: now many extensions peek two seeds and
>spread split candidates among them, some with subtle but noisy
>mistakes
>4. Better way of key compares (this thread, actually)
>5. Split in many portions

Okay, I would try to do more advancements step by step.

I do not understand the problem of choosing subtree as an alternative for penalty. What do yo mean by choosing subtree function?


There will be more questions coming, hope you will be comfortable with that~


Best wishes.

--

Dong



发件人: Andrew Borodin <borodin@octonica.com>
发送时间: 2017年6月16日 16:48:04
收件人: Tom Lane
抄送: Yuan Dong; pgsql-hackers@postgresql.org
主题: Re: [HACKERS] 答复: GiST API Adancement
 
2017-06-16 17:06 GMT+03:00 Tom Lane <tgl@sss.pgh.pa.us>:
> Yuan Dong <Doffery@hotmail.com> writes:
>> ·¢¼þÈË: Andrew Borodin <borodin@octonica.com>
>>> I think there is one more aspect of development: backward
>>> compatibility: it's impossible to update all existing extensions. This
>>> is not that major feature to ignore them.
>
>> I should still maintain original API of GiST after modification.
>
> To put a little context on that: we have always felt that it's okay
> to require extension authors to make small adjustments when going to
> a new major release.

Then maybe it worth to consider more general API advancement at once?
Here's my wish list:
1. Choose subtree function as an alternative for penalty
2. Bulk load support
3. Better split framework: now many extensions peek two seeds and
spread split candidates among them, some with subtle but noisy
mistakes
4. Better way of key compares (this thread, actually)
5. Split in many portions

Best regards, Andrey Borodin.

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

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: [HACKERS] Getting server crash on Windows when using ICU collation
Следующее
От: Devrim Gündüz
Дата:
Сообщение: Re: [HACKERS] how are the rpms configured that are available inPostgreSQL RPM Building Project - Yum Repository