RE: [HACKERS] optimizer pruning problem

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgreSQL(dot)org>, "Roberto Cornacchia" <rcorna(at)tin(dot)it>
Subject: RE: [HACKERS] optimizer pruning problem
Date: 1999-09-08 09:42:50
Message-ID: 000501bef9de$844198e0$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > When the join is between attnos < 0 (such as oids), the selectivity is
> > estimated as 0.5 (leading to very bad size estimates), since this code
> > in function compute_clause_selec (clausesel.c):
>
> > if (relid1 > 0 && relid2 > 0 && attno1 > 0 && attno2 > 0)
> > ...
> > else
> > s1 = (Cost) (0.5);
>
> > So what is the aim of the last two and conditions?
>
> That's a bug, I guess. -1 is used to signal "couldn't find the
> attribute", but there's no real need to check *both* relid and attno
> to determine that. It should consider positive relid and negative
> attno to be valid.
>
> Since vacuum doesn't record statistics for the system attributes,
> there probably also needs to be a hack in the code that looks in
> pg_statistic so that it will produce reasonable estimates. We
> should assume that OID has perfect disbursion, for sure. I don't
> know if we can assume anything much about the other sys attributes...
>

CTID has perfect disbursion too. The selectivity is necessary
in order to compute rows of scan using TIDs,though we couldn't
use WHERE restriction on ctid now.

Regards.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christof Petig 1999-09-08 11:16:59 Re: [HACKERS] vacuum analyze
Previous Message Thomas Lockhart 1999-09-08 03:01:42 Re: [HACKERS] main tree is (slightly) damaged