On Mon, Aug 8, 2011 at 10:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm a bit concerned by the fact that you've only tested this on one
> operating system, and thus the performance characteristics could be
> quite different elsewhere. The comment in mdextend also points out
> a way in which this might not be a win --- did you test anything besides
> read-only scenarios?
Nope.
On Mon, Aug 8, 2011 at 10:49 AM, Andres Freund <andres@anarazel.de> wrote:
> I don't think its a good idea to replace lseek with fstat in the long run. The
> likelihood that the lockless generic_file_llseek will get included seems rather
> high to me. In contrast to that fstat will always be more expensive than that
> as its going through a security check and then the fs' getattr implementation
> (which actually takes a lock on some fs).
*scratches head* I understand that stat() would need a security
check, but why would fstat()?
I think both of you raise good points. I wasn't too enthusiastic
about this approach either. It's not very appealing to adopt an
approach where the right performance decision is going to depend on
operating system, file system, kernel version, core count, and
workload. We could add a GUC, but it would be pretty annoying to have
a setting that won't matter for most people at all, except
occasionally when it makes a huge difference.
I wasn't aware that was any current activity around this on the Linux
side. But Andres' comments made me Google it again, and now I see
this:
https://lkml.org/lkml/2011/6/16/800
Andes, any idea what the status of that patch is? I'm not clear on
how Linux works in terms of things getting upstreamed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company