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
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
