On Thu, Aug 30, 2012 at 04:37:37PM -0400, Bruce Momjian wrote:
> On Tue, May 29, 2012 at 03:54:59PM -0700, Mark Dilger wrote:
> > I was imagining that this would be a trap for linux developers
> > who saw nothing wrong with their code until it made it to the
> > build/test farm. That's pretty far
Tom Lane
> To: Mark Dilger
> Cc: "pgsql-hackers@postgresql.org"
> Sent: Tuesday, May 29, 2012 3:42 PM
> Subject: Re: [HACKERS] Performance patch for Win32
>
> Mark Dilger writes:
> > I am hesitant to write a function like AllocateDirWithFilePattern
> > if the
ch v2.
From: Tom Lane
To: Mark Dilger
Cc: "pgsql-hackers@postgresql.org"
Sent: Tuesday, May 29, 2012 3:42 PM
Subject: Re: [HACKERS] Performance patch for Win32
Mark Dilger writes:
> I am hesitant to write a function like AllocateDirWithFilePattern
> if the pattern is
Mark Dilger writes:
> I am hesitant to write a function like AllocateDirWithFilePattern
> if the pattern is simply ignored on non-Windows. In my patch,
> the pattern underspecified the files, and the ad-hoc matching code
> applied to all the returned files tightened that up. But a person
> could
2:30 PM
Subject: Re: [HACKERS] Performance patch for Win32
Mark Dilger writes:
> 4) Other places in the PostgreSQL sources where directory
> iteration is needed should probably use a pattern if possible
> when running on Windows. Thus, it might make more
> sense to have a version of
Mark Dilger writes:
> 4) Other places in the PostgreSQL sources where directory
> iteration is needed should probably use a pattern if possible
> when running on Windows. Thus, it might make more
> sense to have a version of ReadDir that explicitly takes a
> pattern, and use that version of ReadD
This is a patch against src/backend/storage/file/fd.c
taken from 9.2beta1.
This patch is submitted for review and comments, not
for application to the code base. *WIP*
This patch addresses a performance problem stemming
from the use of FindFirstFile() and FindNextFile() to
iterate over a direct
