> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
>
> > Hmmm,who solved ????
> > * -spinlock stuck problem when elog(FATAL) and elog(ERROR) inside bufmgr
>
> I thought you or Tatsuo fixed that. I will remove the mark.
>
I have had a fix for it for 3 months but not committed because I don't
know how WAL would change it.
OK I would commit it after some checking.
> >
> > And I have felt that the followings are almost same.
> > * Allow LIMIT ability on single-table queries that have no
> ORDER BY to use
> > a matching index [limit]
> > * Improve LIMIT processing by using index to limit rows
> processed [limit]
> > * Have optimizer take LIMIT into account when considering index scans
> > [limit]
> >
> > And Isn't it preferable to omit 'in ORDER BY' from
> > * Use indexes in ORDER BY for restrictive data sets, min(), max()
> > ?
>
> I have now made it two items:
>
> * Use indexes in ORDER BY for restrictive data sets
> * Use indexes in ORDER BY for min(), max()
>
> We currently do not use indexes to handle ORDER BY because it is slower,
> but for queries returning only a few rows, we could use the index and
> skip the ORDER BY. Not sure if this is done yet, or if it is important.
>
Tom has changed to take IndexScan into account even when no qual exists.
* -Allow optimizer to prefer plans that match ORDER BY(Tom)
Currently optimizer is too eager to use index scan. He is planning to take
limit into account AFAIK, He has mentioned it many times and I have been
looking forward to his change.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp