Bruce Momjian wrote:
>
> > Ok. It seems that statistics which is within optimizer's reach is quite
> > poor, so optimizer can't always make sane predictions. And, I am
> > afraid, improving statistics gathering will require major rewrite of code.
> >
> > So there should at least be some way to gi
> Ok. It seems that statistics which is within optimizer's reach is quite
> poor, so optimizer can't always make sane predictions. And, I am
> afraid, improving statistics gathering will require major rewrite of code.
>
> So there should at least be some way to give hints to optimizer,
> shouldn'
Bruce Momjian wrote:
> > -> Index Scan using gindex on btable (cost=2.05 rows=1 width=4)
> > -> Hash (cost=399.00 rows=1 width=4)
> > -> Seq Scan on btable (cost=399.00 rows=1 width=4)
> > -
>
> You can't use in index here because an IN is not select
> But look here:
> -
> adb=> EXPLAIN SELECT * FROM atable WHERE atable.cfield = btable.cfield AND
> atable.afield IN (SELECT btable.bfield WHERE btable.bfield=10);
> NOTICE: QUERY PLAN:
>
> Hash Join (cost=1483.00 rows=1 width=24)
> -> Seq Scan on atable (cost=399.00 rows=
