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.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, I'm
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
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 don't see
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
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
regression=#
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
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
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
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
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
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
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 as:
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.
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 index,
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
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 see doing col
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
We (Oleg and me) would like to present patch implements partial match for GIN
index and two extensions which use this new feature. We hope that after short
review they will be committed to CVS.
This work was sponsored by EnterpriseDB.
http://www.sigaev.ru/misc/partial_match_gin-0.7.gz
20 matches
Mail list logo
