Skip site navigation (1) Skip section navigation (2)


From: Gregory Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Martijn van Oosterhout" <kleptog(at)svana(dot)org>,"Simon Riggs" <simon(at)2ndquadrant(dot)com>,"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
Date: 2006-12-15 16:10:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)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

In response to

pgsql-performance by date

Next:From: Steven FlattDate: 2006-12-15 16:21:35
Subject: Re: Insertion to temp table deteriorating over time
Previous:From: Tom LaneDate: 2006-12-15 15:57:25

pgsql-hackers by date

Next:From: Ted PetroskyDate: 2006-12-15 16:15:42
Subject: Re: libpq.a in a universal binary
Previous:From: Christopher BrowneDate: 2006-12-15 16:07:07
Subject: Re: invalid input syntax for type timestamp.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group