On Mon, Dec 03, 2007 at 02:31:04PM -0500, Vivek Khera wrote:
> having too many indexes is bad, as you have just added a *lot* of
> overhead for every insert/update/delete in that you must update all
> the extra indexes.
>
> there is some fine balance in between, which takes a lot of experience
CREATE INDEX objectcustomfieldvalues1 ON objectcustomfieldvalues
USING btree (customfield, objecttype, objectid, content);
CREATE INDEX objectcustomfieldvalues2 ON objectcustomfieldvalues
USING btree (customfield, objecttype, objectid);
The second index is redundant to the first. Depending
On Nov 30, 2007, at 2:31 PM, Kenneth Marshall wrote:
Here is a list of indexes that we use here. Check your schema
to see if you are missing any. You should not be getting a
sequential scan.
sequential scans are not automatically bad. if your result set is
more than a certain percentage of
Mark,
Here is a list of indexes that we use here. Check your schema
to see if you are missing any. You should not be getting a
sequential scan.
Ken
-INDEXes from rt schema--
CREATE INDEX acl1 ON acl USING btree (rightname, objecttype, objectid,
principaltype, pri
>
> -> Seq Scan on tickets main (cost=0.00..17539.97 rows=1485 width=168)
> (actual time=0.040..846.740 rows=298633 loops=1)
> Filter: status)::text = 'open'::text) OR ((status)::text =
> 'new'::text) OR ((status)::text = 'stalled'::text) OR ((status)::text =
> 'resolved'::text)) A
This is possibly slightly OT, if so I apologize. I'm most of the way
through getting RT to behave under postgres, however I seem to be
hitting a problem with the query optimizer.
When RT tries to pull out the ticket history for a user it runs the
following query
SELECT DISTINCT main.* FROM
