From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
---|---|
To: | Vincenzo Melandri <vmelandri(at)imolinfo(dot)it> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Seq scan on big table, episode 2 |
Date: | 2012-10-31 13:04:55 |
Message-ID: | 509121F7.30505@optionshouse.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 10/31/2012 05:55 AM, Vincenzo Melandri wrote:
> on People:
> CREATE UNIQUE INDEX people_pkey ON people USING btree (key1, key2)
> CREATE INDEX people_pkey_hash_loc ON people USING hash (key1);
> CREATE INDEX people_pkey_hash_id ON people USING hash (key2);
I can't say why it would ignore the first index in this particular JOIN,
but you might as well discard both of those hash indexes. Also,
people_pkey_hash_loc is basically pointless anyway, as the database can
use the first column in a multi-column index as if it were a single
column index.
I *can* ask you why you're using HASH indexes, though. They're not WAL
logged, so they can't be replicated, and they're also not crash safe.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2012-10-31 13:29:44 | Re: Slow query, where am I going wrong? |
Previous Message | Vincenzo Melandri | 2012-10-31 11:46:59 | Re: Seq scan on big table, episode 2 |