Teodor Sigaev wrote:
>> 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.
> But way is better than nothing. In really, that way was chosen to have
> fast merge of (potentially) hundreds of sorted lists of ItemPointers.
> Other ways is much slower.

How about forcing the use of a bitmap index scan, and modify the indexam
API so that GIN could a return a lossy bitmap, and let the bitmap heap
scan do the rechecking?

>> I don't think the storage size of tsquery matters much, so whatever is
>> the best solution in terms of code readability etc.
> That was about tsqueryesend/recv format? not a storage on disk. We don't
> require compatibility of binary format of db's files, but I have some
> doubts about binary dump.

We generally don't make any promises about cross-version compatibility
of binary dumps, though it would be nice not to break it if it's not too
much effort.

>> 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?
> No, wildspeed use the same operator ~~
> match_special_index_operator() isn't called at all: in
> match_clause_to_indexcol() function is_indexable_operator() is called
> before match_special_index_operator() and returns true.
>
> expand_indexqual_opclause() sees that operation is a OID_TEXT_LIKE_OP
> and calls prefix_quals() which fails because it wishes only several
> Btree opfamilies.

Oh, I see. So this assumption mentioned in the comment there:

/*
* LIKE and regex operators are not members of any index opfamily,
* so if we find one in an indexqual list we can assume that it
* was accepted by match_special_index_operator().
*/

is no longer true with wildspeed. So we do need to check that in
expand_indexqual_opclause() then.

>>> NOTICE 2: it seems to me, that similar technique could be implemented
>>> for ordinary BTree to eliminate hack around LIKE support.
>> LIKE expression. I wonder what the size and performance of that would
>> be like, in comparison to the proposed GIN solution?
>
> GIN speeds up '%foo%' too - which is impossible for btree. But I don't
> like a hack around LIKE support in BTree. This support uses outflank
> ways missing regular one.

You could satisfy '%foo%' using a regular and a reverse B-tree index,
and a bitmap AND. Which is interestingly similar to the way you proposed
to use a TIDBitmap within GIN.

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