Re: Problems with ordering (can't force query planner to use an index)

From: Tom Lane
Subject: Re: Problems with ordering (can't force query planner to use an index)
Date: ,
Msg-id: 17008.1236115625@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Problems with ordering (can't force query planner to use an index)  (Sebastjan Trepca)
List: pgsql-performance


Sebastjan Trepca <> writes:
> It thinks there are even less rows in the set:

>                ->  Index Scan using core_accessor_fresh_idx on
> core_accessor  (cost=0.00..8955.44 rows=2440 width=92) (actual
> time=0.056..53.107 rows=69312 loops=1)
>                      Index Cond: ((slot_id = 472) AND (slot_type_id =
> 119) AND (label = ''::text) AND (user_id = 0) AND (role = 0) AND
> (publish_state >= 60))

Maybe you should get rid of this six-column index, if you'd rather the
query didn't use it.  It seems a tad overspecialized anyway.

            regards, tom lane


pgsql-performance by date:

From: Scott Marlowe
Date:
Subject: Re: work_mem in high transaction rate database
From: Akos Gabriel
Date:
Subject: Re: work_mem in high transaction rate database