On Fri, 05 Nov 2004 10:07:38 -0500, Rod Taylor <pg@rbt.ca> wrote:
> > It seems to me that a query saying "SELECT column FROM table WHERE
> > column LIKE 'AA%';" should be just as fast or very close to the first
> > case up above. However, explain tells me that this query is not using
> > the index above, which is what's not making sense to me.
>
> It looks for an exact expression match, and doesn't know about values
> which are equal.
>
> You can provide both clauses.
>
> WHERE column LIKE 'A%' and column LIKE 'AA%';
I see. That's not really optimal either however as you can probably
see already.. adding AB, AC, AD...AZ is likely to be pretty bogus and
at the least is time consuming.
Matt Clark was right that it will use a standard index, which is in
fact what it's doing right now in the "SELECT column WHERE column LIKE
'AA%';" case.. however as I said, the table has millions of rows --
currently about 76 million, so even a full index scan is fairly slow.
The machine isn't all that hot performance wise either, a simple dual
800 P3 with a single 47GB Seagate SCSI. The only redeeming factor is
that it has 2GB of memory, which I'm trying to make the most of with
these indexes.
So assuming this partial index situation isn't going to change (it
seems like it would be a fairly simple fix for someone that knows the
pg code however) I'm wondering if a subselect may speed things up any,
so I'm going to investigate that next.
Perhaps.. SELECT column FROM (SELECT column FROM table WHERE column
LIKE 'A%') AS sq WHERE column LIKE 'AA%';
The query planner thinks this will be pretty fast indeed, and does use
the index I am after.
OS is, of course, FreeBSD.