Tom Lane <tgl@sss.pgh.pa.us> writes:
> On machines where gettimeofday is slow (and last I heard there were
> still lots of them), any such thing would be a disaster
> performance-wise. I'm still afraid to add more gettimeofday's into the
> query parse/plan/execute code path, even though it would greatly ease
> the problem of figuring out whether re-planning is worthwhile.
Excuse my ignorance here, but is SIGALARM less of a problem? Then you
could ask the system for an alarm next second and count the alarms
rather than poll the clock. We don't need high precision in both those
cases I guess.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support