Re: [PERFORM] Tuning queries on large database

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Valerie Schneider DSI/DEV" <Valerie(dot)Schneider(at)meteo(dot)fr>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: [PERFORM] Tuning queries on large database
Date: 2004-08-04 13:06:54
Message-ID: 6EE64EF3AB31D5448D0007DD34EEB34101AF1F@Herge.rcsinc.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
> The result is that for "short queries" (Q1 and Q2) it runs in a few
> seconds on both Oracle and PG. The difference becomes important with
> Q3 : 8 seconds with oracle
> 80 sec with PG
> and too much with Q4 : 28s with oracle
> 17m20s with PG !
>
> Of course when I run 100 or 1000 parallel queries such as Q3 or Q4,
> it becomes a disaster !
> I can't understand these results. The way to execute queries is the
> same I think. I've read recommended articles on the PG site.
> I tried with a table containing 30 millions rows, results are similar.

I don't trust the Oracle #s. Lets look at Q4: returns 3 million rows.
Using your #s of 160 fields and 256 bytes, your are asking for a result
set of 160 * 256 * 3M = 12 GB! This data has to be gathered by the
disk, assembled, and sent over the network.

I don't know Oracle, but it probably has some 'smart' result set that
uses a cursor behind the scenes to do the fetching.

With a 3M row result set, you need to strongly consider using cursors.
Try experimenting with the same query (Q4), declared as a cursor, and
fetch the data in 10k blocks in a loop (fetch 10000), and watch the #s
fly.

Merlin

Browse pgsql-general by date

  From Date Subject
Next Message Valerie Schneider DSI/DEV 2004-08-04 13:18:16 Re: [PERFORM] Tuning queries on large database
Previous Message Valerie Schneider DSI/DEV 2004-08-04 12:44:43 Tuning queries on large database