Re: A Better Way? (Multi-Left Join Lookup)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David Johnston" <polobo(at)yahoo(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: A Better Way? (Multi-Left Join Lookup)
Date: 2012-07-21 17:36:15
Message-ID: 21258.1342892175@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David Johnston" <polobo(at)yahoo(dot)com> writes:
> So,
> EXPLAIN SELECT function_call(...) -- yields a planner expectation of 1 row
> [Whereas]
> EXPLAIN SELECT * FROM function_call(...) -- yields a planner expectation of
> "result_rows" which defaults to 1000

Hm ...

> Was this an intentional design decision to override the result_rows estimate
> of the function if it is used in the select list?

Not so much an intentional decision as just that nobody ever did
anything about it.

In general, SRFs in the target list are considered a legacy feature,
which we're going to deprecate as soon as we have LATERAL so that
there's a better-defined substitute. So I'd not want to expend a lot
of work on this. But it probably would be possible to extract the row
count estimates nearly for free while extracting the target list's cost
estimate, which we already have to make a pass over the expressions for.
Let me go look at that ...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2012-07-21 21:47:37 Re: A Better Way? (Multi-Left Join Lookup)
Previous Message Craig Ringer 2012-07-21 12:36:01 Re: Why is an ISO-8859-8 database allowing values not within that set?