Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group