From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Alexey V(dot) Meledin" <avm(at)webclub(dot)ru> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: planner complaints (was approve VKPts5 unsubscribe pgsql) |
Date: | 2000-04-03 14:32:06 |
Message-ID: | 20160.954772326@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
"Alexey V. Meledin" <avm(at)webclub(dot)ru> writes:
> What mean "???" at (**).
It's probably a MATERIALIZE node. The 6.5 explain-printer didn't have
code to recognize MATERIALIZE, so it prints like that. (Fixed for 7.0.)
> Not optimal way I think
Possibly not. It's hard to tell when you evidently have never vacuumed
your database. Those tiny row counts and near-zero costs are presumably
bogus ... but if the planner thinks those tables are small, it's going
to generate plans accordingly. You need to run a VACUUM, or preferably
VACUUM ANALYZE, to update the statistics the planner needs.
> 2. I've replace btree indexes on relation
> AND atd.ifs_data_id = def.ifs_data_id;
> with:
> create index itd_hash_data_id on ifs_tree_default USING HASH (ifs_data_id);
> create index iatd_hash_data_id on ifs_account_tree_data USING HASH (ifs_data_id);
Why would you do that? The hash index method doesn't have any advantage
over btree that I can see, and it's got a lot of disadvantages.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dalphin | 2000-04-03 19:36:03 | Re: Hash Indexes. (Was: planner complaints) |
Previous Message | Alexey V. Meledin | 2000-04-03 11:48:05 | Re: approve VKPts5 unsubscribe pgsql |