On Fri, 2006-06-09 at 10:00 -0400, Tom Lane wrote: > I think the bottom line here is that there are some machines out there > where gettimeofday() is fast enough for our purposes, and some where > it is nowhere near fast enough. And that kernel-level fixes may be > possible for some of the latter, but not all, and we shouldn't hold our > breath waiting for that to happen anyway.
Agreed. The issue seems to be some systems are set to get exactly correct times and some are set to return a time (possibly imprecise) with low overhead. Even if fixes existed, OS packagers may not pick the right one of those two options for our purposes for EA. (We might prefer accuracy to speed for other parts of PostgreSQL anyway). I propose we revert the sampling patch (sorry Martijn) and go with the patch to have an explain_analyze_timing parameter (default=on). That way we'll have an option to turn off timing *if* we happen to be running on a OS/hw combo that sucks *and* trying to run large enough EAs that we care. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
