Re: [NOVICE] Postgres storing time in strange manner

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: [NOVICE] Postgres storing time in strange manner
Date: 2002-09-18 00:03:40
Message-ID: 200209180003.g8I03eQ07965@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thomas Lockhart wrote:
> ...
> > > > Hard to imagine why anyone would want such an optimization. How much
> > > > faster could it possibly be?
> > > Back in ye bad olde days, there was probably an order-of-magnitude
> > > difference between the speed of a float multiply and that of a float
> > > divide; so this used to be a pretty standard sort of optimization.
> > > I can remember doing the equivalent thing by hand in source code.
> > > On modern hardware I doubt it makes much difference...
>
> The speed difference is still there; you can't do a divide with one pass
> through a barrel shifter, which is how the multiply operations were sped
> up. I vaguely recall something like a 40:1 ratio on a 604 PowerPC but
> that may not be accurate, or may be for integers which have similar
> issues.

Wow, 40:1 is a major difference.

> > And you would have to do a heck of a lot of them to see a difference.
>
> ?? Some applications *do* do a heck of a lot of them ;)

Yep, I am sure. The question is whether there is ever a reason to use
such a flag on the database code. My guess is no.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2002-09-18 04:07:33 Re: Schemas not available for pl/pgsql %TYPE....
Previous Message Bruce Momjian 2002-09-17 22:42:19 Re: [NOVICE] Postgres storing time in strange manner