From: | Jack Orenstein <jack(dot)orenstein(at)hds(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Postgres optimizer choosing wrong index |
Date: | 2008-10-23 17:15:57 |
Message-ID: | 4900B14D.6050804@hds.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Researching this some more, it appears to be the case that VACUUM (by itself, no
ANALYZE) is changing the optimizer's behavior. Here is a self-contained test:
select '*** drop t';
drop table t cascade;
select '*** create t(dh, fh, nm, filler)';
create table t (dh int, fh int, nm int, filler char(500));
select '*** create index on (dh, fh)';
create index idx_df on t(dh, fh);
select '*** create index on (dh, nm)';
create index idx_dn on t(dh, nm);
select '*** explain select * from t where dh = 1 and fh = 2';
explain select * from t where dh = 1 and fh = 2;
select '*** vacuum t (no analyze)';
vacuum t;
select '*** explain select * from t where dh = 1 and fh = 2';
explain select * from t where dh = 1 and fh = 2;
This output was produced by 7.4.8. Version 8.3.4 uses the "wrong" execution plan
both before and after the vacuum.
Jack
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-10-23 17:16:26 | Re: [HACKERS] Hot Standby utility and administrator functions |
Previous Message | Tom Lane | 2008-10-23 17:15:51 | Re: Postgres optimizer choosing wrong index |