From: Gregory Stark <gsstark@mit.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Martijn van Oosterhout <kleptog@svana.org>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Kelly Burkhart <kelly.burkhart@gmail.com>
Cc: Evgeny Gridasov <eugrid@fpm.kubsu.ru>
Cc: pgsql-performance@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2
Date: 15 Dec 2006 11:10:10 -0500
Message-ID: <87mz5pgmxp.fsf@stark.xeocode.com> (raw)
In-Reply-To: <9096.1166197556@sss.pgh.pa.us>
References: <20061214163230.d46f0138.eugrid@fpm.kubsu.ru>
<21146.1166112702@sss.pgh.pa.us>
<20061214192920.c75385d6.eugrid@fpm.kubsu.ru>
<21516.1166114475@sss.pgh.pa.us>
<fa1e4ce70612141543o8866d7fg417eca88ce9b1344@mail.gmail.com>
<29450.1166141131@sss.pgh.pa.us>
<1166178488.3882.56.camel@silverbirch.site>
<20061215105008.GD958@svana.org>
<87irgdiccg.fsf@enterprisedb.com>
<9096.1166197556@sss.pgh.pa.us>
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Gregory Stark <stark@enterprisedb.com> writes:
> > 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.
>
> You've got to be kidding. Surely it's glibc's responsibility, not ours,
> to implement gettimeofday correctly for the hardware.
Except for two things:
a) We don't really need gettimeofday. That means we don't need something
sensitive to adjustments made by ntp etc. In fact that would be actively bad.
Currently if the user runs "date" to reset his clock back a few days I bet
interesting things happen to a large explain analyze that's running.
In fact we don't need something that represents any absolute time, only time
elapsed since some other point we choose. That might be easier to implement
than what glibc has to do to implement gettimeofday fully.
b) glibc may not want to endure an overhead on every syscall and context
switch to make gettimeofday faster on the assumption that gettimeofday is a
rare call and it should pay the price rather than imposing an overhead on
everything else.
Postgres knows when it's running an explain analyze and a 1% overhead would be
entirely tolerable, especially if it affected the process pretty much evenly
unlike the per-gettimeofday-overhead which can get up as high as 100% on some
types of subplans and is negligible on others. And more to the point Postgres
wouldn't have to endure this overhead at all when it's not needed whereas
glibc has no idea when you're going to need gettimeofday next.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: gsstark@mit.edu, tgl@sss.pgh.pa.us, kleptog@svana.org, simon@2ndquadrant.com, kelly.burkhart@gmail.com, eugrid@fpm.kubsu.ru, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2
In-Reply-To: <87mz5pgmxp.fsf@stark.xeocode.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox