Re: Fwd: Question on Trigram GIST indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ERR ORR <rd0002(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Fwd: Question on Trigram GIST indexes
Date: 2013-01-23 03:05:11
Message-ID: 3718.1358910311@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

ERR ORR <rd0002(at)gmail(dot)com> writes:
>> Queries which use "WHERE "TST_PAYLOAD" LIKE 'SEAT%'" go to the btree
>> index as it should.
>> Queries which use "WHERE "TST_PAYLOAD" LIKE '%EAT%'" *should* use the
>> GIST index but do a full table scan instead.

Are you sure it "should" use the index for that? That query doesn't
look very selective to me --- it might well be deciding that a seqscan
is cheaper. You could try forcing the issue with enable_seqscan = off
to see if the query is really unable to match the index, or it just
doesn't like the cost estimate.

> Would it help to `ALTER DATABASE set lc_collate = 'C'`,supposing that is
> possible? (Oracle doesn't allow that iirc)

FWIW, I think you do want the index to have the database's default
collation, otherwise it could only match LIKE clauses that explicitly
specify the same non-default collation.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2013-01-23 07:03:23 Re: proposal: fix corner use case of variadic fuctions usage
Previous Message Edson Richter 2013-01-22 20:14:18 Re: What is the impact of "varchar_pattern_ops" on performance and/or memory