Re: BUG #6269: Anomaly detection - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #6269: Anomaly detection
Date
Msg-id 4EAABC620200002500042837@gw.wicourts.gov
Whole thread Raw
In response to Re: BUG #6269: Anomaly detection  (goudvis <paul.stapersma@gmail.com>)
Responses Re: BUG #6269: Anomaly detection
List pgsql-bugs
goudvis <paul.stapersma@gmail.com> wrote:
> Robert Haas wrote:
>>
>> I would be curious to see (updated, corrected) results on older
>> versions.
>
> If I am correct, Kevin Grittner is writing a review of the code
> and the testing methods. I think it would be wise to wait for the
> outcome of this. Afterwards, I could post the code and the
> execution instructions for anyone who wants to test his or her
> system. Another approach is to do the testing myself, but I don't
> know when I have the time.

Actually, since we (mostly you) found explanations for all the
disallowed phenomena, with no PostgreSQL anomalies showing when
using the corrected test code, I was going to call it done.  Well,
except that I think some of your tests are interesting enough to ask
whether it was OK to try to integrate some of the related SQL into
C-based tests in the optional PostgreSQL regression tests.  (They
probably run too long to include in the main "make check" set.)
If I could get them running in that environment, I think they could
stress a different-enough set of code paths to be worth including.

Regarding the Java code used in your tests, the only issues I found
which I didn't mention to you off list were stylistic or
performance-related.  Since the performance issues would apply to
both MySQL and PostgreSQL, I'm not too worried about them in terms
of comparative numbers.  I anyone wanted to consider the absolute
numbers as significant, I could pass along a few tips.

-Kevin

pgsql-bugs by date:

Previous
From: goudvis
Date:
Subject: Re: BUG #6269: Anomaly detection
Next
From: Mischa POSLAWSKY
Date:
Subject: plperl no longer provides string representations of composite values