On 2008-12-19, at 13:07, Tom Lane wrote:
Grzegorz Jaskiewicz writes:
Filter: (NOT (hashed subplan))
^^
If 8.3 does that, and 8.4 doesn't, it's most likely because you are
using different work_mem settings.
you're right, as always :)
My point is, why is planner choos
Grzegorz Jaskiewicz writes:
>Filter: (NOT (hashed subplan))
^^
If 8.3 does that, and 8.4 doesn't, it's most likely because you are
using different work_mem settings.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
and the plan on 8.4:
gj=# explain select a.a from a where a not in (select a from b);
QUERY PLAN
-
Seq Scan on a (cost=99035.00..257874197565.00 rows=300 width=4)
Filter: (NOT (subplan))
true, but as soon as I drop indices on both tables:
root=# explain analyze select a.a from a where a not in (select a from
b);
QUERY PLAN
--
>>> Gregory Stark wrote:
> Grzegorz Jaskiewicz writes:
>
>> all I know, is that the same query will work on 8.3 in reasonably
> acceptable
>> time frame.
>>
>
> Because I see the exact same plan -- in fact with the exact same
cost:
>
>
> Welcome to psql 8.3.3, the PostgreSQL interactive te
Grzegorz Jaskiewicz writes:
> all I know, is that the same query will work on 8.3 in reasonably acceptable
> time frame.
>
Because I see the exact same plan -- in fact with the exact same cost:
Welcome to psql 8.3.3, the PostgreSQL interactive terminal.
Type: \copyright for distribution ter
Grzegorz Jaskiewicz writes:
> all I know, is that the same query will work on 8.3 in reasonably acceptable
> time frame.
What plan do you get in 8.3?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
--
Sent via p
all I know, is that the same query will work on 8.3 in reasonably
acceptable time frame.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Gregory Stark writes:
> Tom Lane writes:
>> Yeah. NOT IN does not have the right semantics to become an antijoin.
> If we noticed that the columns in the subquery are all guaranteed to be not
> null could we do it then?
I think you'd also have to know that the outer-query value isn't null,
plu
Tom Lane writes:
> Gregory Stark writes:
>> I think Postgres can't do better because there could be a NULL in the
>> subquery. If there's a NULL in the subquery then no record would match.
>
> Yeah. NOT IN does not have the right semantics to become an antijoin.
If we noticed that the columns
Gregory Stark writes:
> I think Postgres can't do better because there could be a NULL in the
> subquery. If there's a NULL in the subquery then no record would match.
Yeah. NOT IN does not have the right semantics to become an antijoin.
FWIW, you can use a NOT EXISTS:
select a.a from a where
Grzegorz Jaskiewicz writes:
> gj=# explain select a.a from a where a not in (select a from b);
>QUERY PLAN
> -
> Seq Scan on a (cost=99035.00..257874197565.00 rows=300 width=4)
>Filte
create table a(a int not null);
insert into a(a) select generate_series(1,600);
create table b as select * from a where a%10 <> 0;
create index fooa on a(a);
alter table b alter column a set not null;
create index foob on b(a);
vacuum analyze verbose;
gj=# explain select a.a from a where a
13 matches
Mail list logo
