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.
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 |