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

Re: AW: [HACKERS] Caution: tonight's commits force initdb

From: Theo Kramer <theo(at)flame(dot)co(dot)za>
To: Zeugswetter Andreas IZ5 <Andreas(dot)Zeugswetter(at)telecom(dot)at>
Cc: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: AW: [HACKERS] Caution: tonight's commits force initdb
Date: 1999-08-24 15:30:22
Message-ID: 37C2BA8E.BD66B6F6@flame.co.za (view raw or flat)
Thread:
Lists: pgsql-hackers
Zeugswetter Andreas IZ5 wrote:
> 
> > Hmm,Index scan is chosen to select all rows.
> > AFAIK,sequential scan + sort is much faster than index scan in
> > most cases.
> >
> >       cost of index scan < cost of sequential scan + cost of sort
> >
> This is usually true. It might need resources though that are not available,
> e.g. 8 GB sort space. It also depends on whether the application is
> interested in
> first row (interactive), or all row performance (batch). Other DB's can
> switch modes
> to decide on the wanted behavior. So I think there is no yes/no decision on
> this.

I feel the decision should be based on all resources required including
CPU, Memory, and I/O by both the server and all clients. In my experience the
index scan *always* comes out on top on average for small, medium and large
result sets with single row fetch. Now if only we can get postgres to support 
single row fetch without having to use transactions and cursors... then I 
believe that postgres could give Informix and Oracle a serious run for 
their money.

--------
Regards
Theo

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 1999-08-24 16:20:22
Subject: Re: [HACKERS] vacuum process size
Previous:From: Tom LaneDate: 1999-08-24 15:05:28
Subject: Re: [HACKERS] vacuum process size

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