On Wed, Aug 19, 2009 at 3:00 PM, Josh Berkus wrote:
> Tom, Greg, Robert,
>
> Here's my suggestion:
>
> 1. First, estimate the cost of the node with a very pessimistic (50%?)
> selectivity for the calculation.
There is no such thing as a pessimistic selectivity estimation. Right
now a lot of thing
Tom, Greg, Robert,
Here's my suggestion:
1. First, estimate the cost of the node with a very pessimistic (50%?)
selectivity for the calculation.
2. If the cost hits a certain threshold, then run the calculation
estimation on the histogram.
That way, we avoid the subtransaction and other overhea
Greg Stark writes:
> On Wed, Aug 19, 2009 at 7:22 PM, Tom Lane wrote:
>> It may be that a subtransaction will actually be acceptable overhead,
>> as long as we don't go overboard and invoke this mechanism for "simple"
>> WHERE clauses. Hard to tell without coding it up and testing it though.
> A
On Wed, Aug 19, 2009 at 7:22 PM, Tom Lane wrote:
>
> It may be that a subtransaction will actually be acceptable overhead,
> as long as we don't go overboard and invoke this mechanism for "simple"
> WHERE clauses. Hard to tell without coding it up and testing it though.
Are you looking for volunt
Greg Stark writes:
> Another thought. In the above case it would actually be fine to catch
> the error with PG_TRY() without a subtransaction. As long as no shared
> database state has been modified when the error is thrown then the
> subtransaction isn't needed to roll them back.
I think catchin
Greg Stark writes:
> We could add another flag in pg_proc for functions which cannot throw
> an error. Perhaps all index operator class operators be required to
> use such functions too?
It would be an extremely small set. For starters, anything that returns
a pass-by-reference data type would b
On Wed, Aug 19, 2009 at 3:16 PM, Greg Stark wrote:
> On Wed, Aug 19, 2009 at 3:53 AM, Tom Lane wrote:
>> * The expression might throw an error for some inputs, for instance
>> (1 / field) < 0.5
>> which would fail on zero. We could recover by wrapping the whole
>> estimation process in a su
On Wed, Aug 19, 2009 at 3:53 AM, Tom Lane wrote:
> * The expression might throw an error for some inputs, for instance
> (1 / field) < 0.5
> which would fail on zero. We could recover by wrapping the whole
> estimation process in a subtransaction, but that seems really expensive.
> I though
On Tue, Aug 18, 2009 at 10:53 PM, Tom Lane wrote:
> There were two different complaints today about the planner's inability
> to make good estimates for WHERE conditions involving bit AND tests,
> such as
> (field & 8) = 0
> (field & 8) <> 0
> (field & 127) = field
>
> I'm not
There were two different complaints today about the planner's inability
to make good estimates for WHERE conditions involving bit AND tests,
such as
(field & 8) = 0
(field & 8) <> 0
(field & 127) = field
I'm not particularly eager to try to put in special-case knowledge
for
10 matches
Mail list logo
