You’re right, a lot of information is missing but I’m unsure that the other information will make too much difference. I could drop all the other indexes on the table which aren’t used here and the queries would still use the indexes they are currently using. I appreciate the idea that a boolean column selectivity might not be great. I’ve just tried creating indexes as follows: CREATE INDEX messageq17 ON messageq_table USING btree (staff_ty, staff_id, incoming, inactive, entity_id); CREATE INDEX messageq18 ON messageq_table USING btree (staff_ty, staff_id); When running query 2 as it stands the same thing happens, it still uses the messageq1 index. The query is logically the same as using max, you are correct, but it’s generated on the fly so the limit or the queried column may change. The query plans were for the second query as I’m unsure that the first query is really relevant, it was simply there to justify the messageq1 index. Thanks, From: Robert Klemme [mailto:shortcutter@xxxxxxxxxxxxxx] On Thu, Aug 2, 2012 at 4:54 PM, Russell Keane <Russell.Keane@xxxxxxxxxx> wrote: Using PG 9.0 and given 2 queries (messageq_current is a view on the messageq_table): select entity_id from messageq_current where entity_id = 123456; select entity_id from messageq_current where incoming = true and inactive = false and staff_ty = 2 and staff_id = 2 order by entity_id desc limit 1; and 2 indexes (there are 15 indexes in total but they are left out here for brevity): messageq1: CREATE INDEX messageq1 ON messageq_table USING btree (entity_id); And messageq4: CREATE INDEX messageq4 ON messageq_table USING btree (inactive, staff_ty, staff_id, incoming, tran_dt);
select max(entity_id) as entity_id from messageq_current where incoming = true and inactive = false and staff_ty = 2 and staff_id = 2;
|