David Johnston wrote:
> varchar(100)
> The other option to index words via the full-text search capabilities.
Or for columns this short, a similarity search on a trigram index.
http://www.postgresql.org/docs/current/interactive/pgtrgm.html
--
Kevin Grittner
EnterpriseDB: http://www.enterpris
On 7 April 2013 15:52, Kevin Grittner wrote:
> David Johnston wrote:
>
> > varchar(100)
>
> > The other option to index words via the full-text search capabilities.
>
> Or for columns this short, a similarity search on a trigram index.
>
> http://www.postgresql.org/docs/current/interactive/pgtr
ERR ORR wrote:
> the fact that in 9.2.4 it is so bad that a simple query sometimes
> does not finish after 10+ minutes with incessant disk activity
> tends to look like a problem to me.
Try running a VACUUM FREEZE ANALYZE; command on the database, under
a database superuser ID. If you upgraded
This doesn't seem either buggy or strange...
An index on the ordering of that column is not helpful in handling a
leading wildcard, and so the query optimizer will, in such cases, revert,
correctly, to using a sequential scan and filtering the results.
If you have cases where this sort of wildcar
ERR ORR writes:
> My understanding from your replies is that this behavior with *b-tree
> indices* is not considered a bug but rather a case of "works as designed",
> yet still and apart from the solution of my particular problem, the fact
> that in 9.2.4 it is so bad that a simple query sometimes
