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()
