Re: Performance for seq. scans

From: Jules Bean <jules(at)jellybean(dot)co(dot)uk>
To: Mitch Vincent <mitch(at)venux(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Performance for seq. scans
Date: 2000-07-26 14:44:47
Message-ID: 20000726154447.D30047@grommit.office.vi.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jul 26, 2000 at 10:34:39AM -0400, Mitch Vincent wrote:
> The FTI trigger code that's distributed with PostgreSQL now actually breaks
> the words up into two character substrings.
>
> I re-wrote it to eliminate duplicates and only split up the words based on
> whitespace and delimiters -- if you did this you could still use LIKE to
> match based on substrings, then you would have the added speed of an index
> scan..
>
> Jules:
>
> select * from table_a where foo like '%bar%'
>
> Depending on the table type of foo, that doesn't have to do a seq scan... If
> it's anything but text, you can create an index on it -- LIKE can use
> indexes. If it is type text then I would look into using the FTI stuff in
> contrib. If you want mine, let me know however it sounds like the
> distributed version would be more suited to what you'd like to do.

Hmm. Colour me confused.

You're suggesting I can use a conventional index on 'foo'? Well,
certainly, there is such an index on the table anyhow (since some
queries do use it) but I don't understand. Surely LIKE only uses
indexes when the string match is anchored on the left? Certainly
that's my understanding of indexes, and it's what the docs say...

OTOH, are you saying that the FTI code in 7.0.2 contrib does in fact
do the 'index all occuring 2-char substring' trick? I must go and
investigate that straight away. Many thanks.

Jules

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2000-07-26 14:46:27 Re: Is Pg 7.0.x's Locking Mechanism BROKEN?
Previous Message Ron Peterson 2000-07-26 14:39:30 Re: free auction project with Postgres