From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Dilger <markdilger(at)yahoo(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance patch for Win32 |
Date: | 2012-05-29 22:42:45 |
Message-ID: | 5498.1338331365@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Dilger <markdilger(at)yahoo(dot)com> 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 just as well overspecify the pattern and then they would get
> different behavior on Windows vs. non-Windows, with fewer
> files returned by FindNextFile() than would have matched the
> ad-hoc pattern.
Well, if you're imagining that we wouldn't need to test carefully on
both Windows and non-Windows, I think that's a pipe dream. As an
example, your proposal of AllocateDirWithFilePrefix would only work
consistently across platforms if the prefix didn't contain anything
that Windows thought was a pattern metacharacter. (This might never
come up, but I'm not too sure what the metacharacters are on Windows.)
Having said that, I have nothing particularly against the idea of
specifying a prefix rather than an arbitrary pattern. I'm just
saying it'll still need testing. Also, I wonder how many of the
potential stat-equivalent operations we'll be unable to optimize
away with the more restricted definition. Using a tighter pattern
on Windows seems basically free (modulo testing) if we accept that
it's Windows-only.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2012-05-29 22:49:39 | Re: pg_upgrade libraries check |
Previous Message | Mark Dilger | 2012-05-29 22:28:48 | Re: Performance patch for Win32 |