On Sun, 2004-04-18 at 19:09, Tom Lane wrote:
> Markus Bertheau <[EMAIL PROTECTED]> writes:
> > , 17.04.2004, 01:45, Tom Lane :
> >> The planner sees that as "where scope = "
> >> and falls back to a default estimate. It won't simplify a sub-select
> >> to a constant. (Some people consider that
Well, the example shown is simplified version.
Now, let's see a little 'real' example (still
simplified version):
Table test is same as before:
\d test
Table "public.test"
Column | Type | Modifiers
-+--+---
id | inte
Rod Taylor <[EMAIL PROTECTED]> writes:
>> It's the only way to prevent it from simplifying when you don't want it
>> to.
> I'm having a difficult time coming up with a circumstance where that is
> beneficial except when stats are out of whack.
Try trawling the archives --- I recall several cases
Markus Bertheau <[EMAIL PROTECTED]> writes:
> В Сбт, 17.04.2004, в 01:45, Tom Lane пишет:
>> The planner sees that as "where scope = "
>> and falls back to a default estimate. It won't simplify a sub-select
>> to a constant. (Some people consider that a feature ;-).)
> Why?
It's the only way to
Ð ÐÐÑ, 17.04.2004, Ð 01:45, Tom Lane ÐÐÑÐÑ:
> The planner sees that as "where scope = "
> and falls back to a default estimate. It won't simplify a sub-select
> to a constant. (Some people consider that a feature ;-).)
Why?
Thanks
--
Markus Bertheau <[EMAIL PROTECTED]>
Litao Wu <[EMAIL PROTECTED]> writes:
> When I included a subquery, the estimated rows (1240)
> is way too high as shown in the following example.
> select * from test
> where scope=(select 10);
The planner sees that as "where scope = "
and falls back to a default estimate. It won't simplify a s
Hi,
When I included a subquery, the estimated rows (1240)
is way too high as shown in the following example.
Can someone explain why? Because of this behavior,
some of our queries use hash join instead of nested
loop.
Thanks,
select version();
version
