Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] ORDER BY optimisations

From: Hannu Krosing <hannu(at)trust(dot)ee>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: jwieck(at)debis(dot)com, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] ORDER BY optimisations
Date: 1998-10-31 14:53:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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.


In response to

pgsql-hackers by date

Next:From: Ryan KirkpatrickDate: 1998-10-31 15:10:51
Subject: Re: [PATCHES] Patches for Pgsql on Linux/Alpha (RE: Last Call...)
Previous:From: Karl AuerDate: 1998-10-31 11:30:02
Subject: RE: [HACKERS] Why is libcurses added to build by configure?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group