| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kelly Burkhart" <kelly(dot)burkhart(at)gmail(dot)com>, "Evgeny Gridasov" <eugrid(at)fpm(dot)kubsu(dot)ru>, <pgsql-performance(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PERFORM] EXPLAIN ANALYZE on 8.2 |
| Date: | 2006-12-15 12:15:59 |
| Message-ID: | 87irgdiccg.fsf@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
"Martijn van Oosterhout" <kleptog(at)svana(dot)org> writes:
> BTW, doing gettimeofday() without kernel entry is not really possible.
That's too strong a conclusion. Doing gettimeofday() without some help from
the kernel isn't possible but it isn't necessary to enter the kernel for each
call.
There are various attempts at providing better timing infrastructure at low
overhead but I'm not sure what's out there currently. I expect to do this what
we'll have to do is invent a pg_* abstraction that has various implementations
on different architectures. On Solaris it can use DTrace internally, on Linux
it might have something else (or more likely several different options
depending on the age and config options of the kernel).
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2006-12-15 12:19:00 | Re: unixware and --with-ldap |
| Previous Message | Albe Laurenz | 2006-12-15 12:06:08 | Re: unixware and --with-ldap |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2006-12-15 12:20:46 | Re: [HACKERS] EXPLAIN ANALYZE on 8.2 |
| Previous Message | Ron | 2006-12-15 11:55:52 | Re: New to PostgreSQL, performance considerations |