Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Поиск
Список
Период
Сортировка
От Mark Rofail
Тема Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Дата
Msg-id CAJvoCuvdSx8fizeFYLLf6xeJHG6mDF+z2vcuKKrD25RBahjX8Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (David Steele <david@pgmasters.net>)
Ответы Re: [HACKERS] GSoC 2017: Foreign Key Arrays  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Hello David,

On Tue, Apr 10, 2018 at 3:47 PM, David Steele <david@pgmasters.net> wrote:
You should produce a new version by then that addresses Alvaro's
concerns and I imagine that will require quite a bit of discussion and
work. 

I'll get working.
I'll produce a patch with two alternate versions, one with and one without the GIN operators.

On 3/7/18 5:43 AM, Alvaro Herrera wrote:
so the performance was measured to see if the GIN operator was
worth it, and the numbers are pretty confusing (the test don't seem
terribly exhaustive; some numbers go up, some go down, it doesn't appear
that the tests were run more than once for each case therefore the
numbers are pretty noisy
 Any ideas how to perform more exhaustive tests ? 

On 3/26/18 4:50 PM, Mark Rofail wrote:
> On Wed, Jan 31, 2018 at 1:52 AM, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
>
>      The issue I see is that
>     ginqueryarrayextract() needs to make a copy of the search key but to do
>     so it needs to know the type of anyelement (to know if it needs to
>     detoast, etc). But there is as far as I can tell no way to check the
>     type of anyelement in this context.
>
> If there is any way to  obtain a copy of the datum I would be more than
> happy to integrate the GIN operator to the patch.
 
as I said before we need a way to obtain a copy of a datum to comply with the context of  ginqueryarrayextract()

Best Regards

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

Предыдущее
От: Pavan Deolasee
Дата:
Сообщение: Re: Bugs in TOAST handling, OID assignment and redo recovery
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: crash with sql language partition support function