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
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 |