Re: [GENERAL] gin index trouble
От | Rob Sargent |
---|---|
Тема | Re: [GENERAL] gin index trouble |
Дата | |
Msg-id | 0b1a550a-58f4-bf7d-6c16-3c4c0cea5d63@gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] gin index trouble (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] gin index trouble
|
Список | 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. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: