This still does not fix the problem.
I had done my patch to try to mimic the way 8.0 had handled the math
with the remainders, but to carry it over another bucket (day).
The problem that I see is that we are taking day_remainder and
multiplying by USECS_PER_DAY. Which is a double * int64, thus there is
the precision loss there.
I think initial division by the factor can't be helped, but repeatedly
doing more floating point math on with it is causing the rounding error.
Thanks,
-rocco
> -----Original Message-----
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: Saturday, July 23, 2005 10:54 AM
> To: Rocco Altier
> Cc: Michael Glaesemann; pgsql-patches@postgresql.org;
> pgsql-hackers@postgresql.org; ohp@pyrenet.fr
> Subject: Re: [HACKERS] regressin failure on latest CVS
>
>
> Rocco Altier wrote:
> > This patch fixes the interval regression on my AIX box
> (kookaburra) by
> > only doing integer math on the interval, instead of
> float/double math.
> >
> > I think this is the correct way to handle this, since it's
> an integer
> > data type.
> >
> > I don't know if it will fix Olivier's problem, since I
> wasn't able to
> > reproduce it.
> >
>
> I have changed the way I compute the remainder values --- instead of
> using multiplication, I use division and then subtraction.
> This should
> fix your rounding problem. Looking at your fix, I don't see
> how adding
> USECS changes things because the factor is already a float,
> but I think
> the problem was more the way I was computing the remainders.
>
> Patch attached --- let me know if it does not fix your problem.
>
> --------------------------------------------------------------
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
