Phil Frost [EMAIL PROTECTED] writes:
I have an optimization I'd like to see which I think should be pretty
easy for someone familiar with the planner code to implement.
I've done something about this for 8.2. It could possibly be improved
on, in that it's not terribly smart about where to
Tom Lane wrote:
regression=# explain select * from (select * from onek a where expensive(0))
ss1 join (select * from onek b where expensive(1)) ss2 using(unique1);
QUERY PLAN
Alvaro Herrera [EMAIL PROTECTED] writes:
I note that the rowcount is not altered by the one-time filter. Is this
an issue? I imagine the problem is not being able to estimate the
number of rows that pass the filter.
That's intentional. The filter is either going to pass all or none of
the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I note that the rowcount is not altered by the one-time filter. Is this
an issue? I imagine the problem is not being able to estimate the
number of rows that pass the filter.
That's intentional. The filter is either going to
Greg Stark [EMAIL PROTECTED] writes:
I'm not sure why it's not pulling up from the left side of the left join
though. That might be a bug. What PG version is this exactly?
In fact it doesn't even pull it up out of a regular join. I looked into this
when it was first brought up on IRC and as
I have an optimization I'd like to see which I think should be pretty
easy for someone familiar with the planner code to implement. My
situation is this: I have an application using veil[1]. Essentially, I
have a schema private and another public. Private contains regular
tables, where private
On Wed, Jun 28, 2006 at 10:35:37AM -0400, Phil Frost wrote:
I have an optimization I'd like to see which I think should be pretty
easy for someone familiar with the planner code to implement. My
situation is this: I have an application using veil[1]. Essentially, I
have a schema private and
On Wed, Jun 28, 2006 at 05:11:59PM +0200, Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 10:35:37AM -0400, Phil Frost wrote:
I have an optimization I'd like to see which I think should be pretty
easy for someone familiar with the planner code to implement. My
situation is this: I
Phil Frost [EMAIL PROTECTED] writes:
The planner in fact can move the function around without changing the
output.
Not when it's within the nullable side of an outer join --- moving a
WHERE clause up out of that would make the difference between no row
out, and a null-extended row out, which
On Wed, Jun 28, 2006 at 11:40:52AM -0400, Tom Lane wrote:
Phil Frost [EMAIL PROTECTED] writes:
The planner in fact can move the function around without changing the
output.
Not when it's within the nullable side of an outer join --- moving a
WHERE clause up out of that would make the
Tom Lane [EMAIL PROTECTED] writes:
Phil Frost [EMAIL PROTECTED] writes:
The planner in fact can move the function around without changing the
output.
Not when it's within the nullable side of an outer join --- moving a
WHERE clause up out of that would make the difference between no row
11 matches
Mail list logo
