RE: [HACKERS] selectivity calculation for or_clause is wrong ?

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" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] selectivity calculation for or_clause is wrong ?
Date: 1999-07-21 01:31:58
Message-ID: 000301bed318$d2fca0c0$2801007e@cadzone.tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Wednesday, July 21, 1999 12:32 AM
> To: Hiroshi Inoue
> Cc: pgsql-hackers
> Subject: Re: [HACKERS] selectivity calculation for or_clause is wrong ?
>
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Why is valid_or_clause(clausenode) necessary ?
>
> Looks like a waste of cycles to me too.
>

It's not only a waste of cycles.
For exmaple,

1.explain select key1 from b where someitem in (1);

NOTICE: QUERY PLAN:

Seq Scan on b on b (cost=1638.49 rows=261 width=4)

2.explain select key1 from b where someitem in (1,2);

NOTICE: QUERY PLAN:

Seq Scan on b on b (cost=1638.49 rows=773 width=4)

3.explain select key1 from b where someitem in (1,2,3);

NOTICE: QUERY PLAN:

Seq Scan on b on b (cost=1638.49 rows=1274 width=4)

rows of each plan 261 : 773 : 1274 not = 1 : 2 : 3.
It's nearly = 1 :3 :5.

elements of or_clause except its first element are evaluated
twice and the results are accumlated.

Regards.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hub.Org News Admin 1999-07-21 05:45:08
Previous Message The Hermit Hacker 1999-07-21 01:15:23 PostgreSQL 6.5.1 Released ...