Re: [HACKERS] Re: [BUGS] General Bug Report: Bug in optimizer

Bruce Momjian <maillist@candle.pha.pa.us>

From: Bruce Momjian <maillist@candle.pha.pa.us>
To: vadim@krs.ru (Vadim Mikheev)
Cc: bamby@marka.net.ua, hackers@postgreSQL.org
Date: 1999-03-18T20:13:23Z
Lists: pgsql-bugs, pgsql-hackers
> Agreed, this is ok as long as
> 
> vac=> create table table1 (field1 int);
> CREATE
> vac=> insert into table1 values (1);
> INSERT 1583349 1
> vac=> create index i_table1__field1 on table1 (field1);
> CREATE
> vac=> explain select * from table1 where field1 = 1;
> NOTICE:  QUERY PLAN:
> 
> Seq Scan on table1  (cost=1.03 size=1 width=4)
> 
> - SeqScan is used for small tables.
> 
> So, only bug reported is left.

I see it now.  The -4 is coming over as a unary minus, and a 4.  That is
OK, because the executor knows how to deal with a unary minus, but the
optimizer thinks it is a operator and a constant, which it is, but it
does not know how to index an operator with a constant.

Unary minus is probably the not only operator that can be auto-folded
into the constant.  In fact, it may be valuable to auto-fold all
operator-constant pairs into just constants.

In fact, that may not be necessary.  If we code so that we check that
the right-hand side is totally constants, and make the change in the
executor(if needed), we can just pass it all through.  However, we need
the constant for optimizer min/max comparisons when using >, but we
could do without that if needed, so we don't have to evaluate operators
and functions outside the executor.

The quick fix may be to just make sure -4 does not use unary minus in
the parser.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026