| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | marko(at)joh(dot)to |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #8598: Row count estimates of partial indexes |
| Date: | 2013-11-17 16:29:15 |
| Message-ID: | 28474.1384705755@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
marko(at)joh(dot)to writes:
> We have the following partial index on a small subset of a larger table:
> "index_transactions_transaction_balance_details" btree (transactionid)
> WHERE NOT processed AND accountbalancesdailyid IS NOT NULL
> However, querying with the WHERE clause completely ignores the
> pg_class.reltuples value for the index:
Yup. Row count estimates are derived by estimating the selectivity of the
given WHERE clauses and multiplying by the (estimated) current table size.
In the particular case you show here, with a partial index that *exactly*
matches the WHERE clause, we could get a better answer by looking at the
index size --- but that doesn't scale to any less simplistic case, such
as a query with additional WHERE clauses.
It's also important to realize that reltuples for an index is a whole lot
less trustworthy than it is for a table; ANALYZE doesn't update the
former, for example. And scaling from the last-reported VACUUM stats
to current reality is going to be shakier.
So on the whole, I don't think this would be a good idea.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Tiikkaja | 2013-11-17 19:55:30 | Re: BUG #8598: Row count estimates of partial indexes |
| Previous Message | Kevin Grittner | 2013-11-17 15:34:10 | Re: BUG #8598: Row count estimates of partial indexes |