On Thu, Mar 13, 2014 at 6:15 AM, Bruce Momjian <br...@momjian.us> wrote: > On Wed, Mar 12, 2014 at 01:58:14PM -0700, Peter Geoghegan wrote: >> The use case you describe here doesn't sound like something similar to >> full text search. It sounds like something identical. >> >> In any case, let's focus on what we have right now. I think that the >> indexing facilities proposed here are solid. In any case they do not >> preclude working on better indexing strategies as the need emerges. > > Keep in mind that if we ship an index format, we are going to have > trouble changing the layout because of pg_upgrade. pg_upgrade can mark > the indexes as invalid and force users to reindex, but that is less than > idea.
Well these are just normal gin and gist indexes. If we want to come up with new index operator classess we can still do that and keep the old ones if necessary. Even that seems pretty unlikely from past experience. I'm actually pretty sanguine even about keeping the GIST opclass. If it has bugs then the bugs only affect people who use this non-default opclass and we can fix them. It doesn't risk questioning any basic design choices in the patch. It does sound like the main question here is which opclass should be the default. From the discussion there's a jsonb_hash_ops which works on all input values but supports fewer operators and a jsonb_ops which supports more operators but can't handle json with larger individual elements. Perhaps it's better to make jsonb_hash_ops the default so at least it's always safe to create a default gin index? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers