Re: planner complaints (was approve VKPts5 unsubscribe pgsql)

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

In response to

Responses

Browse pgsql-sql by date

  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