From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | robert(at)webtent(dot)com |
Cc: | PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Creating indexes |
Date: | 2007-12-10 18:08:32 |
Message-ID: | dcc563d10712101008p35ff8d8y536d52584ae9bafe@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Dec 10, 2007 10:53 AM, Robert Fitzpatrick <lists(at)webtent(dot)net> wrote:
> I have a PHP 5 app using pgsql 8.2 and a HTML table of clients now grown
> to almost 10,000 loading 25 per page. There is a filter feature atop all
> seven columns in the table listing (all varchar except one date column).
> Also, sorting can be done by clicking any column header. Some complain
> of speed during filtering or clearing the filter. I want to create some
> indexes to see if this will help as I'm sure it will since there are
> none currently.
>
> Now my question, would it be better to create one index with all columns
> in the table -or- a separate index for each column field? I was assuming
> the latter, but would the index with all columns be beneficial as well?
As previously mentioned, making multicolumn indexes may not be your best bet.
If you have an index on (field1, field2, field3) and do a query that
doesn't select based on field1, you won't use that index. OTOH, if
you always select certain fields for order by / where fieldx= then it
might be a good bet.
Most importantly, if your database is not initialized to locale=C,
then you will need to use varchar_ops operators on it. Otherwise your
db won't be able to use your indexes.
From | Date | Subject | |
---|---|---|---|
Next Message | Ted Byers | 2007-12-10 18:10:21 | Re: SQL design pattern for a delta trigger? |
Previous Message | Josh Harrison | 2007-12-10 17:51:04 | Re: slony question |