| From: | Rod Taylor <ports(at)rbt(dot)ca> |
|---|---|
| To: | Michael Nonemacher <Michael_Nonemacher(at)messageone(dot)com> |
| Cc: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: postgres performance: comparing 2 data centers |
| Date: | 2004-06-04 22:27:08 |
| Message-ID: | 1086388027.67371.92.camel@jester |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> The members table contains about 500k rows. It has an index on
> (group_id, member_id) and on (member_id, group_id).
Yes, bad stats are causing it to pick a poor plan, but you're giving it
too many options (which doesn't help) and using space up unnecessarily.
Keep (group_id, member_id)
Remove (member_id, group_id)
Add (member_id)
An index on just member_id is actually going to perform better than
member_id, group_id since it has a smaller footprint on the disk.
Anytime where both group_id and member_id are in the query, the
(group_id, member_id) index will likely be used.
--
Rod Taylor <rbt [at] rbt [dot] ca>
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
PGP Key: http://www.rbt.ca/signature.asc
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rod Taylor | 2004-06-04 22:29:29 | Re: postgres performance: comparing 2 data centers |
| Previous Message | Michael Nonemacher | 2004-06-04 22:07:52 | Re: postgres performance: comparing 2 data centers |