fstat vs. lseek

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: fstat vs. lseek
Date: 2011-08-08 14:30:38
Message-ID: CA+TgmoawRfpan35wzvgHkSJ0+i-W=VkJpKnRxK2kTDR+HsanWA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

In response to my blog post on lseek contention, someone posted a
comment wherein they proposed using fstat() rather than lseek() to get
file sizes.

http://rhaas.blogspot.com/2011/08/linux-and-glibc-scalability.html

I tried that on a RHEL 6.1 machine with 64-cores running
2.6.32-131.6.1.el6.x86_64, and it's pretty clear that the locking
characteristics are completely different. At 1 client, the lseek
method appears to be slightly faster, although it's not beyond belief
that the difference could be in the noise. Above 40 cores, however,
the fstat method thumps the lseek method up one side and down the
other.

Patch and test results are attached. Test runs are 5-minute runs with
scale factor 100 and shared_buffers=8GB.

Thoughts?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment Content-Type Size
filesize.patch application/octet-stream 1.9 KB
pgbench -S at 32 cores - fstat patch comparison.ods application/vnd.oasis.opendocument.spreadsheet 12.9 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-08-08 14:45:22 Re: fstat vs. lseek
Previous Message Robert Haas 2011-08-08 13:49:27 Re: mosbench revisited