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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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