Re: Broken selectivity with special inet operators

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Broken selectivity with special inet operators
Date: 2011-09-22 00:48:03
Message-ID: 5458.1316652483@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> If you mean the indexscan optimization, we do know how to estimate the
>> cost of the indexscans, because that depends mostly on the behavior of
>> the added < or > condition(s). This does not imply knowing how to
>> estimate the behavior of >>= itself.

> If we can estimate the cost of the indexscan, why can't we estimate the
> rowcount?

Because the estimated rowcount is derived long before we consider whether
to use an indexscan at all, and indeed must be computable whether the
table has any related index or not. The special-indexscan-qual code is
*not* a substitute for providing a selectivity estimator.

It's possible that we could build simple estimators for these operators
that just turn the problem into a range estimation and then pass it off
to somewhere else, but nobody has tried.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Josh Berkus 2011-09-22 00:54:25 Re: Broken selectivity with special inet operators
Previous Message Josh Berkus 2011-09-22 00:37:15 Re: Broken selectivity with special inet operators