On Mon, 26 Feb 2007, Guillaume Smet wrote:
On 2/26/07, Oleg Bartunov wrote:
Did you rewrite query manually or use rewrite feature of tsearch2 ?
Currently, it's manual. I perform a pg_trgm query for each word of the
search words (a few stop words excluded) and I generate the ts_query
with the
On 2/26/07, Oleg Bartunov wrote:
Did you rewrite query manually or use rewrite feature of tsearch2 ?
Currently, it's manual. I perform a pg_trgm query for each word of the
search words (a few stop words excluded) and I generate the ts_query
with the similar words instead of using the search wo
On Mon, 26 Feb 2007, Guillaume Smet wrote:
On 2/24/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
Thanks for your time.
GiN version, short:
-> Bitmap Heap Scan on tags (cost=8.64..151.79 rows=41 width=0)
(actual time=5.555..30.157 rows=7 loops=1)
Filter: (title % 'foo'::t
On 2/24/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
Thanks for your time.
GiN version, short:
-> Bitmap Heap Scan on tags (cost=8.64..151.79 rows=41 width=0) (actual
time=5.555..30.157 rows=7 loops=1)
Filter: (title % 'foo'::text)
-> Bitmap Index Scan on trgm_id
On Sat, Feb 24, 2007 at 02:04:36AM +0100, Guillaume Smet wrote:
> Could you post EXPLAIN ANALYZE for both queries (after 2 or 3 runs)?
GIST version, short:
amarok=# explain analyze select count(*) from tags where title % 'foo';
QUERY PLAN
Hi Steinar,
On 2/24/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
I'm sorry, I can no longer remember where I needed pg_trgm. Simple testing of
your patch seems to indicate that the GiN version is about 65% _slower_ (18ms
vs. 30ms) for a test data set I found lying around, but I remember t
On Sat, Feb 24, 2007 at 12:09:41AM +0100, Guillaume Smet wrote:
> Could you try to see if the GIN implementation of pg_trgm is faster in
> your cases?
I'm sorry, I can no longer remember where I needed pg_trgm. Simple testing of
your patch seems to indicate that the GiN version is about 65% _slowe
Florian, Steinar,
Could you try to see if the GIN implementation of pg_trgm is faster in
your cases?
Florian, instead of using WHERE similarity(...) > 0.4, you should use
set_limit (SELECT set_limit(0.4);).
I posted it on -patches and it is available here:
http://people.openwide.fr/~gsmet/postg
On Mon, Jan 15, 2007 at 11:16:36AM +0100, Florian Weimer wrote:
> Am I missing something? Or are trigrams just a poor match for my data
> set? Are the individual strings too long, maybe?
FWIW, I've seen the same results with 8.1.x.
/* Steinar */
--
Homepage: http://www.sesse.net/
I've got a table with a few million rows, consisting of a single text
column. The average length is about 17 characters. For the sake of
an experiment, I put a trigram index on that table. Unfortunately, %
queries without smallish LIMITs are ridiculously slow (they take
longer than an hour). A
10 matches
Mail list logo
