Skip to Main Content
  • Questions
  • LINESIZE and displaying data on a screen : the biggest part of execution time?

Breadcrumb

Easter

Question and Answer

Chris Saxon

Thanks for the question, David.

Asked: February 12, 2020 - 10:29 am UTC

Answered by: Chris Saxon - Last updated: February 14, 2020 - 3:04 pm UTC

Category: SQL Plus - Version: 19

Viewed 1000+ times

You Asked

Hello Masters,

I have one big question about the SQL*Plus parameter LINESIZE and the display of datas.

I read in documentation Oracle 19 SQL*Plus : https://docs.oracle.com/en/database/oracle/oracle-database/19/sqpug/sqlplus-users-guide-and-reference.pdf
"8.5.6 SET LINESIZE
SET LINESIZE sets the total number of characters that SQL*Plus displays on one line before beginning a new line.
Keep LINESIZE as small as possible to avoid extra memory allocations and memory copying.
However, if LINESIZE is too small, columns that cannot fit next to each other are put on separate lines. This may reduce performance significantly."

So if this parameter is too small it may reduce performance. I want to see that!

My screen is 32 inches and can display 246 characters on one line.
I fill my screen with "i" and calculate their number.
SQL> SELECT length('iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii') from dual;
LENGTH('IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
----------------------------------------------------------------------------------------------------
            246


My table for this test.
SQL> CREATE TABLE zztest AS SELECT * FROM dba_objects WHERE rownum < 20001;
Table created.

SQL> ALTER TABLE zztest ADD id number;
Table altered.

SQL> UPDATE zztest SET id = rownum;
20000 rows updated.

SQL> commit;
Commit complete.

SQL> ALTER TABLE zztest ADD CONSTRAINT pk_zztest PRIMARY KEY (id);
Table altered.


Total length of characters to display all columns' name of the zztest test table.
SQL> select sum(length(column_name)) from dba_tab_cols where table_name = 'ZZTEST' and owner = 'HR' order by column_name;
SUM(LENGTH(COLUMN_NAME))
------------------------
       283


I flush the buffer cache every time, because I want to read data from disk (the "most" expensive operation as "everyone" says).
I execute my SELECT twice with a FLUSH between them but I only put the display of the first execution to save space (the time is the same for twice).
SQL> set lines 100
SQL> set timing on
SQL> ALTER SYSTEM FLUSH buffer_cache;


What I see is that : columns on nine lines (on my computer).
Time : almost one minute.
SQL> select * from zztest;
OWNER
--------------------------------------------------------------------------------
OBJECT_NAME
--------------------------------------------------------------------------------
SUBOBJECT_NAME
--------------------------------------------------------------------------------
 OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE    CREATED   LAST_DDL_
---------- -------------- ----------------------- --------- ---------
TIMESTAMP     STATUS  T G S  NAMESPACE
------------------- ------- - - - ----------
EDITION_NAME
--------------------------------------------------------------------------------
SHARING     E O A
------------------ - - -
DEFAULT_COLLATION
--------------------------------------------------------------------------------
D S CREATED_APPID CREATED_VSNID MODIFIED_APPID MODIFIED_VSNID       ID
- - ------------- ------------- -------------- -------------- ----------
...
20000 rows selected.

Elapsed: 00:00:56.68



Now I change LINESIZE, I set it at 150.
The output is different : only seven lines for the name of the columns (on my computer) but the time is the same.
SQL> ALTER SYSTEM FLUSH buffer_cache;
SQL> SET LINESIZE 150;

SQL> select * from zztest;
OWNER
--------------------------------------------------------------------------------------------------------------------------------
OBJECT_NAME
--------------------------------------------------------------------------------------------------------------------------------
SUBOBJECT_NAME                 OBJECT_ID
-------------------------------------------------------------------------------------------------------------------------------- ----------
DATA_OBJECT_ID OBJECT_TYPE        CREATED  LAST_DDL_ TIMESTAMP        STATUS  T G S  NAMESPACE
-------------- ----------------------- --------- --------- ------------------- ------- - - - ----------
EDITION_NAME                SHARING     E
-------------------------------------------------------------------------------------------------------------------------------- ------------------ -
O A DEFAULT_COLLATION            D S CREATED_APPID CREATED_VSNID
- - ---------------------------------------------------------------------------------------------------- - - ------------- -------------
MODIFIED_APPID MODIFIED_VSNID       ID
-------------- -------------- ----------
...
20000 rows selected.

Elapsed: 00:00:59.49


I change again LINESIZE, I set it at 300.
The output is different : only 4 lines for the name of the columns (on my computer) AND the time is incredibly low, only ten seconds...
SQL> ALTER SYSTEM FLUSH buffer_cache;
SQL> SET LINESIZE 300;

SQL> select * from zztest;
OWNER                 OBJECT_NAME
-------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------
SUBOBJECT_NAME                 OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE     CREATED   LAST_DDL_ TIMESTAMP    STATUS  T G S  NAMESPACE
-------------------------------------------------------------------------------------------------------------------------------- ---------- -------------- ----------------------- --------- --------- ------------------- ------- - - - ----------
EDITION_NAME                SHARING     E O A DEFAULT_COLLATION              D S CREATED_APPID CREATED_VSNID
-------------------------------------------------------------------------------------------------------------------------------- ------------------ - - - ---------------------------------------------------------------------------------------------------- - - ------------- -------------
MODIFIED_APPID MODIFIED_VSNID       ID
-------------- -------------- ----------
REMOTE_SCHEDULER_AGENT  
...
20000 rows selected.

Elapsed: 00:00:09.97


OK, let's continue! I change again LINESIZE, I set it at 500, more than the size of my screen.
The output is different : only 3 lines for the name of the columns (on my computer) AND the time is again better, only five seconds...
SQL> ALTER SYSTEM FLUSH buffer_cache;
SQL> SET LINESIZE 500;

SQL> select * from zztest;
OWNER                 OBJECT_NAME             SUBOBJECT_NAME                  OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE      CREATED   LAST_DDL_ TIMESTAMP      STATUS  T G S
-------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ---------- -------------- ----------------------- --------- --------- ------------------- ------- - - -
 NAMESPACE EDITION_NAME                   SHARING        E O A DEFAULT_COLLATION        D S CREATED_APPID CREATED_VSNID MODIFIED_APPID MODIFIED_VSNID  ID
---------- -------------------------------------------------------------------------------------------------------------------------------- ------------------ - - - ---------------------------------------------------------------------------------------------------- - - ------------- ------------- -------------- -------------- ----------
REMOTE_SCHEDULER_AGENT               SUBMIT_JOB_RESULTS          20044       PROCEDURE       26-JAN-17 26-JAN-17 2017-01-26:14:43:37 VALID   N N N
  1                    METADATA LINK      N Y N USING_NLS_COMP        N N             19999

20000 rows selected.

Elapsed: 00:00:05.37


Last test : I set LINESIZE to 5000.
The output is different : only 1 lines for the name of the columns (on my computer) AND the time is again better, only four seconds...
However if I am want to copy / paste the result, all the name of the columns are present in Notepad so even if they are not displayed on the screen, they are present on my PC.
SQL> ALTER SYSTEM FLUSH buffer_cache;
SQL> SET LINESIZE 5000;

SQL> select * from zztest;
OWNER                 OBJECT_NAME             SUBOBJECT_NAME                  OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE      CREATED   LAST_DDL_ TIMESTAMP      STATUS  T G S  NAMESPACE EDITION_NAME                     SHARING    E O A DEFAULT_COLLATION          D S CREATED_APPID CREATED_VSNID MODIFIED_APPID MODIFIED_VSNID    ID
-------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------- ---------- -------------- ----------------------- --------- --------- ------------------- ------- - - - ---------- -------------------------------------------------------------------------------------------------------------------------------- ------------------ - - - ---------------------------------------------------------------------------------------------------- - - ------------- ------------- -------------- -------------- ----------
REMOTE_SCHEDULER_AGENT               SUBMIT_JOB_RESULTS          20044       PROCEDURE       26-JAN-17 26-JAN-17 2017-01-26:14:43:37 VALID   N N N     1                      METADATA LINK   N Y N USING_NLS_COMP                N N        19999
...
20000 rows selected.

Elapsed: 00:00:03.80



If I use Autotrace, I see that if I increase LINESIZE, "Physical Reads" and "Consistent gets" decrease but there is a limit to that benefit.
SQL> show linesize
linesize 80
SQL> show pagesize
pagesize 14

SQL> set timing on
SQL> set autotrace on
SQL> ALTER SYSTEM FLUSH buffer_cache;
SQL> select * from zztest;
...
20000 rows selected.

Elapsed: 00:00:57.94

Execution Plan
----------------------------------------------------------
Plan hash value: 3582063246

----------------------------------------------------------------------------
| Id  | Operation   | Name   | Rows  | Bytes | Cost (%CPU)| Time    |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    | 20000 |  2441K|   101   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| ZZTEST | 20000 |  2441K|   101   (0)| 00:00:01 |
----------------------------------------------------------------------------

Statistics
----------------------------------------------------------
 135  recursive calls
   4  db block gets
       1956  consistent gets
 380  physical reads
 220  redo size
    2958855  bytes sent via SQL*Net to client
      15270  bytes received via SQL*Net from client
       1335  SQL*Net roundtrips to/from client
   9  sorts (memory)
   0  sorts (disk)
      20000  rows processed


I change LINESIZE.
SQL> SET LINESIZE 150;
SQL> ALTER SYSTEM FLUSH buffer_cache;

SQL> select * from zztest;
...
20000 rows selected.

Elapsed: 00:00:58.10

Execution Plan
----------------------------------------------------------
Plan hash value: 3582063246

----------------------------------------------------------------------------
| Id  | Operation   | Name   | Rows  | Bytes | Cost (%CPU)| Time    |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    | 20000 |  2441K|   101   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| ZZTEST | 20000 |  2441K|   101   (0)| 00:00:01 |
----------------------------------------------------------------------------

Statistics
----------------------------------------------------------
  85  recursive calls
   4  db block gets
       1806  consistent gets
 379  physical reads
   0  redo size
    2958855  bytes sent via SQL*Net to client
      15270  bytes received via SQL*Net from client
       1335  SQL*Net roundtrips to/from client
   6  sorts (memory)
   0  sorts (disk)
      20000  rows processed


I change LINESIZE.
SQL> SET LINESIZE 300;
SQL> ALTER SYSTEM FLUSH buffer_cache;

SQL> select * from zztest;
...
20000 rows selected.

Elapsed: 00:00:10.12

Execution Plan
----------------------------------------------------------
Plan hash value: 3582063246

----------------------------------------------------------------------------
| Id  | Operation   | Name   | Rows  | Bytes | Cost (%CPU)| Time    |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    | 20000 |  2441K|   101   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| ZZTEST | 20000 |  2441K|   101   (0)| 00:00:01 |
----------------------------------------------------------------------------

Statistics
----------------------------------------------------------
   0  recursive calls
   4  db block gets
       1668  consistent gets
 355  physical reads
   0  redo size
    2958855  bytes sent via SQL*Net to client
      15270  bytes received via SQL*Net from client
       1335  SQL*Net roundtrips to/from client
   0  sorts (memory)
   0  sorts (disk)
      20000  rows processed


I change LINESIZE.
SQL> SET LINESIZE 500;
SQL> ALTER SYSTEM FLUSH buffer_cache;

SQL> select * from zztest;
...
20000 rows selected.

Elapsed: 00:00:05.46

Execution Plan
----------------------------------------------------------
Plan hash value: 3582063246

----------------------------------------------------------------------------
| Id  | Operation   | Name   | Rows  | Bytes | Cost (%CPU)| Time    |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    | 20000 |  2441K|   101   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| ZZTEST | 20000 |  2441K|   101   (0)| 00:00:01 |
----------------------------------------------------------------------------

Statistics
----------------------------------------------------------
   0  recursive calls
   4  db block gets
       1668  consistent gets
 355  physical reads
   0  redo size
    2958855  bytes sent via SQL*Net to client
      15270  bytes received via SQL*Net from client
       1335  SQL*Net roundtrips to/from client
   0  sorts (memory)
   0  sorts (disk)
      20000  rows processed


I set LINESIZE to 5000.
SQL> SET LINESIZE 5000;
SQL> ALTER SYSTEM FLUSH buffer_cache;

SQL> select * from zztest;
20000 rows selected.

Elapsed: 00:00:03.73

Execution Plan
----------------------------------------------------------
Plan hash value: 3582063246

----------------------------------------------------------------------------
| Id  | Operation   | Name   | Rows  | Bytes | Cost (%CPU)| Time    |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    | 20000 |  2441K|   101   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| ZZTEST | 20000 |  2441K|   101   (0)| 00:00:01 |
----------------------------------------------------------------------------

Statistics
----------------------------------------------------------
   0  recursive calls
   4  db block gets
       1668  consistent gets
 355  physical reads
   0  redo size
    2958855  bytes sent via SQL*Net to client
      15270  bytes received via SQL*Net from client
       1335  SQL*Net roundtrips to/from client
   0  sorts (memory)
   0  sorts (disk)
      20000  rows processed



Last last test : I cancel the output of datas on my screen.
Here it is incredible : not even one second!
SQL> show linesize
linesize 80
SQL> show pagesize
pagesize 14

SQL> SET AUTOTRACE TRACEONLY
SQL> ALTER SYSTEM FLUSH buffer_cache;

SQL> select * from zztest;
...
20000 rows selected.

Elapsed: 00:00:00.32

Execution Plan
----------------------------------------------------------
Plan hash value: 3582063246

----------------------------------------------------------------------------
| Id  | Operation   | Name   | Rows  | Bytes | Cost (%CPU)| Time    |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |    | 20000 |  2441K|   101   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| ZZTEST | 20000 |  2441K|   101   (0)| 00:00:01 |
----------------------------------------------------------------------------

Statistics
----------------------------------------------------------
 125  recursive calls
   6  db block gets
       1943  consistent gets
 391  physical reads
   0  redo size
    2958855  bytes sent via SQL*Net to client
      15270  bytes received via SQL*Net from client
       1335  SQL*Net roundtrips to/from client
  13  sorts (memory)
   0  sorts (disk)
      20000  rows processed


To fetch the SAME amount of data from the database to the client, time varies from 57 seconds to 0.3 second...
So the biggest part of the job is done by displaying data on my screen, not by physical reads? Do you agree with that?

In the doc I read "However, if LINESIZE is too small, columns that cannot fit next to each other are put on separate lines. This may reduce performance significantly."" : can you detail that? And, last thing, can you explain me why the cost is so big for displaying data on screen : if I do not display them, my SELECT is executed in only 0.3 seconds?

Thank you very very much for the response,

Best regards,

D. DUBOIS



and we said...

I'm not sure what you're trying to show here. The LINESIZE has no impact on the time it takes to execute your SQL. But it does affect how long it takes SQL*Plus to render the results.

If you measure the SQL execution time in your database (e.g. with the monitor hint), you should find that the database time for all tests is about the same and fairly trivial - in the order of milliseconds.

Most of the time is spent sending and receiving results from the database and SQL*Plus displaying them.

And as the docs say and you've found choosing a small value for linesize causes it to take longer to show the data.

PS - I'm not sure why you want "expensive" physical reads; this just adds another variable (disk I/O) which is irrelevant to testing linesize. Ideally you want NO phsyical reads, as this avoids any extra variance in disk response to influence the results.

and you rated our response

  (4 ratings)

We're not taking reviews currently, so please try again later if you want to add a review.

Reviews

February 13, 2020 - 11:23 am UTC

Reviewer: D. DUBOIS from Paris, FRANCE


Hello Chris,

Thank you for the answer, it is now clearer for me :-)

"The LINESIZE has no impact on the time it takes to execute your SQL. But it does affect how long it takes SQL*Plus to render the results."
It is exactly what I wanted to understand : the value of LINESIZE has a big impact for a SELECT, but not in its execution, only in its render.
I did not remenber that there were the last part in Select :
1) Analyse by CBO
2) Execution by Oracle
3) Fetching datas on the network
4) Render the result on screen by SQL*Plus(I do not know why but I thought it was extremely fast)

Now, I will be aware about : "Most of the time is spent sending and receiving results from the database and SQL*Plus displaying them."

You say : "PS - I'm not sure why you want "expensive" physical reads; this just adds another variable (disk I/O) which is irrelevant to testing linesize."
What I see with the physical reads is that the biggest time (returned by SET TIMING ON) is spend to send and render the result on my screen, not by the I/O from the disk.
When I see that I begin with 56.68 seconds and I finish with 0.32 second with no display, I am completly flabbergasted...
I thought that physicals I/O were the biggest part of a Select like I read it so many time, that's why I wanted to force them. Now I see that the send and render of the result is more expensive than the physicals I/O (in my test).


Last question : "test begins with 56.68 seconds and finishes with 0.32 second with no display", do you agree that 56.36 seconds are spend in sending and rendering datas on my PC?
Or only in rendering (I don't know if with "SET AUTOTRACE TRACEONLY", Oracle sends datas to the client but the client does not display them).

One time again, thank you for the explanations, I understand more Oracle now :-)

D. DUBOIS

Chris Saxon

Followup  

February 13, 2020 - 11:36 am UTC

Physical reads are slow compared to memory access. But when you're selecting large numbers of rows, the time it takes to transfer data over the network and the number of roundtrips between client and database dominates.

February 13, 2020 - 12:08 pm UTC

Reviewer: D. DUBOIS from Paris, FRANCE

Oups, I have the answer...
"Last question : "test begins with 56.68 seconds and finishes with 0.32 second with no display", do you agree that 56.36 seconds are spend in sending and rendering datas on my PC?
Or only in rendering (I don't know if with "SET AUTOTRACE TRACEONLY", Oracle sends datas to the client but the client does not display them)."

The output of "AutotraceTraceonly" is :
"2958855 bytes sent via SQL*Net to client
15270 bytes received via SQL*Net from client
1335 SQL*Net roundtrips to/from client"
We have exactly the same amount of datas send for all the tests. So when I start from 56.68 seconds and finish with 0.32 second, I understand that I win 56 seconds by nor displaying datas with SQL*Plus?

Incredible ...


Chris Saxon

Followup  

February 13, 2020 - 1:04 pm UTC

Run a SQL trace to see what's really going on:

exec DBMS_monitor.session_trace_enable ( null, null, true, true );
select * from ...
exec DBMS_monitor.session_trace_disable;


Then dig out and format the trace file. This will show you exactly what's going on. I suspect you'll see a small CPU time and lots of "SQL Net to/from client" waits.

For details on how to get and read the file see:

https://blogs.oracle.com/sql/how-to-create-an-execution-plan#tkprof

February 14, 2020 - 1:56 pm UTC

Reviewer: D. DUBOIS

OK, I did it with a linesize at 80.

Here an extract of the file, only for my SELECT.
THe column Elapsed = 0.10. Is it in seconds? I think so.
The biggest part of the job is for the roundtrip beetween the server and my computer.
********************************************************************************
SQL ID: gmakm8zzgh3ta Plan Hash: 3582063246

select *
from
 zztest

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.01          0          2          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch     1335      0.02       0.09        354       1668          4       20000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     1337      0.03       0.10        354       1670          4       20000

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 128
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
     20000      20000      20000  TABLE ACCESS FULL ZZTEST (cr=1668 pr=354 pw=0 time=32981 us starts=1 cost=101 size=2500000 card=20000)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                    1335        0.00          0.00
  Disk file operations I/O                        1        0.00          0.00
  db file sequential read                         1        0.00          0.00
  db file scattered read                         19        0.00          0.00
  PGA memory operation                            1        0.00          0.00
  SQL*Net message from client                  1335       71.04        126.15
********************************************************************************


Here the resume at the end of the file, for the whole job in the base for processing my SELECT.
Column elapsed : 0.13 + 0.42 = 0.55 seconds.

********************************************************************************
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.01       0.02          0        304          0           0
Execute      3      0.00       0.01          1        125          0           2
Fetch     1335      0.02       0.09        354       1668          4       20000
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     1340      0.04       0.13        355       2097          4       20002

Misses in library cache during parse: 2
Misses in library cache during execute: 1

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PGA memory operation                            2        0.00          0.00
  SQL*Net message to client                    1336        0.00          0.00
  SQL*Net message from client                  1336       71.04        178.73
  db file sequential read                         1        0.00          0.00
  Disk file operations I/O                        1        0.00          0.00
  db file scattered read                         19        0.00          0.00


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse       13      0.00       0.02          0         86          0           0
Execute    340      0.07       0.16          0         25          0           0
Fetch      481      0.01       0.22          4       1283          0        1783
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      834      0.09       0.42          4       1394          0        1783

Misses in library cache during parse: 8
Misses in library cache during execute: 26

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PGA memory operation                            4        0.00          0.00
  db file sequential read                         4        0.20          0.21

    3  user  SQL statements in session.
   33  internal SQL statements in session.
   36  SQL statements in session.
********************************************************************************


So, if I understand, the database manage my order under 0.55 secondes (process and sends datas) and ALL the rest (59 secondes on my previous test) is only to display data on my screen?

If it is that, you were right, the biggest part of the job is only for SQL*Plus to display data, with many waits about sending data and a very very short time to read datas from disk.


Thank again for your help :-)


Chris Saxon

Followup  

February 14, 2020 - 3:04 pm UTC

Your findings match what I was expecting ;)

ALL the rest (59 secondes on my previous test) is only to display data on my screen?

It's the time taken to get a chunk of rows from the database, display them, then send the request for the next batch of data.

February 14, 2020 - 3:58 pm UTC

Reviewer: D. DUBOIS


Chris, I am progressing thanks to you, you are very good :-)