Mark,
This would only seem to work for trivial functions. Most functions that
I write are themselves dependent on underlying tables, and without any
idea how many rows are in the tables, and without any idea of the
statistical distribution of those rows, I can't really say anything like
Josh Berkus wrote:
Mark,
This would only seem to work for trivial functions. Most functions that
I write are themselves dependent on underlying tables, and without any
idea how many rows are in the tables, and without any idea of the
statistical distribution of those rows, I can't really say
Josh Berkus josh@agliodbs.com writes:
What I'd like to do is implement the constant method for 8.2, and work on
doing the S() method later on. Does that make sense?
I'm not thrilled with putting in a stopgap that we will have to support
forever. The constant method is *clearly* inadequate
Tom,
What I'd like to do is implement the constant method for 8.2, and work
on doing the S() method later on. Does that make sense?
I'm not thrilled with putting in a stopgap that we will have to support
forever. The constant method is *clearly* inadequate for many (probably
most IMHO)
Josh Berkus josh@agliodbs.com writes:
I'm not thrilled with putting in a stopgap that we will have to support
forever. The constant method is *clearly* inadequate for many (probably
most IMHO) practical cases. Where do you see it being of use?
Well, mostly for the real-world use cases where
Josh Berkus wrote:
Tom,
What I'd like to do is implement the constant method for 8.2, and work
on doing the S() method later on. Does that make sense?
I'm not thrilled with putting in a stopgap that we will have to support
forever. The constant method is *clearly* inadequate for many
Mark Dilger wrote:
I've been thinking about this more, and now I don't see why this is an
issue. When the planner estimates how many rows will be returned from a
subquery that is being used within a join, it can't know which
parameters to use either. (Parameters being whatever conditions the
