Re: [HACKERS] ORDER BY optimisations

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: [HACKERS] ORDER BY optimisations
Дата
Msg-id 363B2487.89862DB9@trust.ee
обсуждение исходный текст
Ответ на Re: [HACKERS] ORDER BY optimisations  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
Bruce Momjian wrote:
> 
> > Hallo Jan,
> >
> > Do I remember right that your pathes to speed up ORDER BYs (by
> > omitting them when not needed) did not make it into 6.4 .
> >
> > If that is the case, are they available anywhere ?
> >
> > I really need them (fast) for my new project.
> 
> LIMIT will probably be added to 6.4.1.  


Actually I don't need LIMIT that much (for me using CURSOR/MOVE/FETCH 
is quite ok). The main benefit from LIMIT seems to be the ability 
of giving the (future) optimiser a hint that we actulally need only 
a small part of the whole query so it may be better to use an index.

What I am after, is the patch that removed the redundant sort node 
when the access is already by an index matching the sort.

> Queries that use '%text%' can not use indexes because they are not 
> anchored at the beginning.
> fulltextindex is in contrib for those cases.

It still seems a bit of a cludge, although a useful one as its usage 
is quite different from the use of other indexes. It also seems to be 
quite liberal with wasting space as it makes both an additional table
_and_ an index for the words it indexes.

In fact I'm currently using my own fulltext indexing scheme outside 
the database. I'm planning to work on including it in the pgsql 
backend, once I figure out how the extending of access methods works.

--------------
Hannu


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Karl Auer
Дата:
Сообщение: RE: [HACKERS] Why is libcurses added to build by configure?
Следующее
От: Ryan Kirkpatrick
Дата:
Сообщение: Re: [PATCHES] Patches for Pgsql on Linux/Alpha (RE: Last Call...)