Wildspeed was designed as an example application of the GIN's partial
match and as a useful extension for *short* strings. It's also good
standalone demonstration of GIN API. We tried to stay away from full text
search, parser, word delimiters and etc.
From that point of view it might be
usefu
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> http://www.sigaev.ru/misc/partial_match_gin-0.10.gz
> http://www.sigaev.ru/misc/tsearch_prefix-0.9.gz
> http://www.sigaev.ru/misc/wildspeed-0.12.tgz
I've applied the first two of these with minor editorialization (mostly
fixing documentation). However,
There seems to be something broken here: it's acting like prefix search
is on all the time, eg
I'm in sackcloth and ashes...
Fixed and extended regression tests.
http://www.sigaev.ru/misc/tsearch_prefix-0.9.gz
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> http://www.sigaev.ru/misc/partial_match_gin-0.10.gz
> http://www.sigaev.ru/misc/tsearch_prefix-0.8.gz
> http://www.sigaev.ru/misc/wildspeed-0.12.tgz
There seems to be something broken here: it's acting like prefix search
is on all the time, eg
regressio
It might be useful, although I don't see any usage of that right now. I'll add
this option.
Ping? I'd like to get this patch out of the way.
I'm very sorry for long delay.
http://www.sigaev.ru/misc/partial_match_gin-0.10.gz
http://www.sigaev.ru/misc/tsearch_prefix-0.8.gz
http://www.sigaev.ru/
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Looking at this now. Wouldn't it be a good idea for comparePartial
>> to get the strategy number of the operator? As you have it set up,
>> I doubt that an opclass can support more than one partial-match
>> operator.
> It might be useful, although I d
Looking at this now. Wouldn't it be a good idea for comparePartial
to get the strategy number of the operator? As you have it set up,
I doubt that an opclass can support more than one partial-match
operator.
It might be useful, although I don't see any usage of that right now. I'll add
this o
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> http://www.sigaev.ru/misc/partial_match_gin-0.9.gz
> Sync with CVS.
Looking at this now. Wouldn't it be a good idea for comparePartial
to get the strategy number of the operator? As you have it set up,
I doubt that an opclass can support more than one
http://www.sigaev.ru/misc/partial_match_gin-0.9.gz
Sync with CVS.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To ma
http://www.sigaev.ru/misc/partial_match_gin-0.8.gz
Reworked interface as it suggested by Gregory
(http://archives.postgresql.org/pgsql-patches/2008-04/msg00199.php)
and move check of index into expand_indexqual_opclause() as suggested by Heikki
(http://archives.postgresql.org/pgsql-patches/2008
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?
Partial match might be used only for one search entry from many. In sext search
example: 'a:* & qwertyuiop' - second lexeme ha
Alvaro Herrera wrote:
Well, LIKE %foo% is supposed to match foo unanchored, but with a btree
(or two btrees) you can only get 'foo' anchored to either end of the
string (or both).
Ah, true.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-patches mailing
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Heikki Linnakangas wrote:
>>> 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.
>>
>> Huh, can you? I can se
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Teodor Sigaev wrote:
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
Heikki Linnakangas wrote:
> Teodor Sigaev wrote:
>> 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 ind
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. I
"Teodor Sigaev" <[EMAIL PROTECTED]> writes:
> - compare function has third (optional) argument, of boolean type, it points
> to
>kind of compare: partial or exact match. If argument is equal to 'false',
>function should produce comparing as usual, else function's result is
>treated a
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
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-
19 matches
Mail list logo