Re: gin index trouble

From: Rob Sargent <robjsargent(at)gmail(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: gin index trouble
Date: 2017-10-30 15:56:14
Message-ID: 0b1a550a-58f4-bf7d-6c16-3c4c0cea5d63@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


> If you can make a test case that (eventually) hits that, we'd be
> interested to see it ...
>

Any hint(s) on what might trigger this sort of thing? I could duplicate
the upload, but I doubt you want the 800K records, 200M input file even
if it did regenerate the problem.

Would select * from <table> order by <gin'd column> show the message?
>> and I um, er, enabled gin on uuid by copying from a thread in this list, as follows:
>> create operator class _uuid_ops
>> default for type _uuid
>> using gin as
>> operator 1 &&(anyarray, anyarray)
>> ,operator 2 @>(anyarray, anyarray)
>> ,operator 3 <@(anyarray, anyarray)
>> ,operator 4 =(anyarray, anyarray)
>> ,function 1 uuid_cmp(uuid, uuid)
>> ,function 2 ginarrayextract(anyarray, internal, internal)
>> ,function 3 ginqueryarrayextract(anyarray, internal, smallint, internal, internal, internal, internal)
>> ,function 4 ginarrayconsistent(internal, smallint, anyarray, integer, internal, internal, internal, internal)
>> ,storage uuid;
> You should not have needed to do that, I think, as the standard
> anyarray GIN opclass should've handled it. Having said that,
> I don't immediately see anything broken about this definition,
> so it seems like it should've worked.

Good to hear.

Thanks.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Geoghegan 2017-10-30 16:15:38 Re: gin index trouble
Previous Message Michael Paquier 2017-10-30 14:35:43 Re: starting PG command line options vs postgresql.con