Re: Re: Heaps of read() syscalls by the postmaster - Mailing list pgsql-hackers

From Matthias Urlichs
Subject Re: Re: Heaps of read() syscalls by the postmaster
Date
Msg-id 20000519091054.C27730@noris.de
Whole thread Raw
In response to Re: Heaps of read() syscalls by the postmaster  ("Matthias Urlichs" <smurf@noris.net>)
Responses RE: Re: Heaps of read() syscalls by the postmaster
List pgsql-hackers
Hi,

short add-on:

> The table has been created (via Perl) thusly:
> [...]

and then 300000 records have been inserted, with unique values of 'id'
of course, before doing the updates I mentioned in my previous post. The
backend does 500 read() calls each INSERT, too, which is equally dog-slow.
Trace of testing program's send() calls:

08:59:20.367593 send(3, "Qinsert into bench1 (id,id2,id3,dummy1) values
(2730,2730,2730,\'ABCDEFGHIJ\')\0", 77, 0) = 77
08:59:20.416391 send(3, "Qinsert into bench1 (id,id2,id3,dummy1) values
(2731,2731,2731,\'ABCDEFGHIJ\')\0", 77, 0) = 77
08:59:20.457082 send(3, "Qinsert into bench1 (id,id2,id3,dummy1) values
(2732,2732,2732,\'ABCDEFGHIJ\')\0", 77, 0) = 77
08:59:20.497766 send(3, "Qinsert into bench1 (id,id2,id3,dummy1) values
(2733,2733,2733,\'ABCDEFGHIJ\')\0", 77, 0) = 77
08:59:20.538928 send(3, "Qinsert into bench1 (id,id2,id3,dummy1) values
(2734,2734,2734,\'ABCDEFGHIJ\')\0", 77, 0) = 77

Trace summary of the server while doing this:

$ sudo strace -c -p 27264
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------84.77    1.224299          60     20301
read10.90   0.157477           8     20573           lseek 3.30    0.047625        1058        45           recv 0.69
0.009914          54       182           write 0.22    0.003168          70        45           send 0.07    0.000955
      21        45        45 ioctl 0.06    0.000899          20        45           time
 
------ ----------- ----------- --------- --------- ----------------
100.00    1.444337                 41236        45 total

i.e., 450 or so read() calls per request, apparently serially scannign
for somethign or other:

$ strace -e lseek -p -pid-of-postmaster
lseek(13, 0, SEEK_SET)                  = 0
lseek(13, 8192, SEEK_SET)               = 8192
lseek(13, 16384, SEEK_SET)              = 16384
lseek(13, 24576, SEEK_SET)              = 24576
lseek(13, 32768, SEEK_SET)              = 32768
lseek(13, 40960, SEEK_SET)              = 40960
lseek(13, 49152, SEEK_SET)              = 49152
lseek(13, 57344, SEEK_SET)              = 57344
lseek(13, 65536, SEEK_SET)              = 65536
lseek(13, 73728, SEEK_SET)              = 73728
lseek(13, 81920, SEEK_SET)              = 81920
lseek(13, 90112, SEEK_SET)              = 90112
lseek(13, 98304, SEEK_SET)              = 98304
lseek(13, 106496, SEEK_SET)             = 106496
lseek(13, 114688, SEEK_SET)             = 114688

I think you'll agree that this kind of query is supposed to use an index.
test=> explain select * from bench1 where id = 123;
NOTICE:  QUERY PLAN:

Index Scan using bench1_index_ on bench1  (cost=0.00..8.14 rows=10 width=24)

EXPLAIN
test=> explain insert into bench1 (id,id2,id3,dummy1) values
test-> (2730,2730,2730,'ABCDEFGHIJ');
NOTICE:  QUERY PLAN:

Result  (cost=0.00..0.00 rows=0 width=0)

EXPLAIN
test=> 

Hmmm... what, no query plan at all???


-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.       |        http://smurf.noris.de/
-- 
Many changes of mind and mood; do not hesitate too long.


pgsql-hackers by date:

Previous
From: Peter Mount
Date:
Subject: RE: LONG: How to migrate data from MS-SQL7 to PostgreSQ L 7.0
Next
From: Hannu Krosing
Date:
Subject: Re: OO Patch