Re: Partial match in GIN

Teodor Sigaev wrote:
> For each
> matched entry all corresponding ItemPointers are collected in TIDBitmap
> structure to effective merge ItemPointers from different entries. Patch
> introduces following changes in interface:

Looking at the patch, you require that the TIDBitmap fits in work_mem in
non-lossy format. I don't think that's acceptable, it can easily exceed
work_mem if you search for some very common word. Failing to execute a
valid query is not good.

> Here there is a unclean issue: now tsquery has new flag to label prefix
> search and cstring representation has backward compatibility, but
> external binary hasn't it now. Now, extra byte is used for storage of
> this flag. In other hand, there 4 unused bits in external binary
> representation (in byte stores weights of lexeme), so it's possible to
> use one of them to store this flag. What are opinions?

I don't think the storage size of tsquery matters much, so whatever is
the best solution in terms of code readability etc.

> NOTICE 1: current index support of LIKE believes that only BTree can
> speed up LIKE and becomes confused with this module with error
> 'unexpected opfamily' in
> prefix_quals(). For this reason, partial match patch adds small check
> before
> calling expand_indexqual_opclause().

Hmm. match_special_index_operator() already checks that the index's
opfamily is pattern_ops, or text_ops with C-locale. Are you reusing the
same operator families for wildspeed? Doesn't it then also get confused
if you do a "WHERE textcol > 'foo'" query by hand?

> NOTICE 2: it seems to me, that similar technique could be implemented
> for ordinary BTree to eliminate hack around LIKE support.

Yep, if you created a b-tree index on the reversed key, that could be
used for LIKE '%foo' expressions. And if you had that in addition to a
regular b-tree index, you could use those two indexes together for any
LIKE expression. I wonder what the size and performance of that would be
like, in comparison to the proposed GIN solution?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com