Thread: optimizer bug report

optimizer bug report

From
"Roberto Cornacchia"
Date:
============================================================================
                        POSTGRESQL BUG REPORT TEMPLATE
============================================================================


Your name  :    Roberto Cornacchia
                             Andrea Ghidini
Your email address :    cornacch@cs.unibo.it
                             ghidini@cs.unibo.it

System Configuration
---------------------
  Architecture (example: Intel Pentium)   :   Intel Pentium II

  Operating System (example: Linux 2.0.26 ELF)  :   Linux 2.2.5-15 ELF

  PostgreSQL version (example: PostgreSQL-6.5)  :   PostgreSQL-6.5

  Compiler used (example:  gcc 2.8.0)  :   gcc egcs-2.91.66


Please enter a FULL description of your problem:
------------------------------------------------
We found a behaviour in the paths pruning that seems to us anomalous even if
it does not corrupt the correctness.
During the enumeration and pruning of the paths, when deciding wether to add
a
new path to the current pathlist and in the situation where
- the pathlist contains an unordered path (cheapest) and some ordered paths
- the newpath is ordered and cheaper than the unordered, but the pathlist
  already contains a path with such an order
it happens that the new path simply replaces the unordered one so that the
new
pathlist contains two paths with the same order, when only the cheaper
should
be kept.
We think the right behaviour should have been to still prune the unordered
path, but not add the new one and instead go on deciding for the new path
insertion with the reminder of the pathlist.





Please describe a way to repeat the problem.   Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
  SELECT relname
  FROM pg_class, pg_index, pg_attribute
  WHERE pg_class.oid=indrelid AND pg_class.oid=attrelid;





If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------
We have fixed the problem and generated a patch mailed to
  pgsql-patches@postgresql.org