That makes sense. Yes, it's quite a number of work to do. :-) I'll take a look at the comments and code and try to understand it.
T
On Thu, Nov 8, 2012 at 6:28 PM, Craig Ringer <craig@xxxxxxxxxxxxxxx> wrote:
On 11/09/2012 09:37 AM, Tianyin Xu wrote:The SQL to the test cases is right there in the regress directory,
> Thanks, Craig,
>
> Yes, I know "context diff". What I don't know is whether + or - some
> rows is a big problem, let's say correctness problem. I didn't write
> the test cases so I don't know what these test cases are exactly doing.
usually with comments explaining what each test is for.
It depends on the test. Some are testing whether the optimizer behaves
> If you tell me the failure of these test cases are severe and not
> acceptable, I'm fine with it. It means these configurations are not
> allowed.
as expected, choosing a particular plan. Some tests assume rows are
being returned in a particular order, so if you change settings you can
see at a glance that while the test fails the output is actually OK.
Others are correctness tests and must produce exactly the the expected
results.
This is generally clear from the test query and comments.
> which assigned a big number to the cpu_index_tuple_cost, affecting theThe planner tests are written for a particular configuration, so if you
> query planner.
change the configuration they won't produce the expected results. That's
OK; just make sure other tests are fine.
It'd be nice to split the tests up into clearer groups - "will fail if
planner settings are changed; WARNING", "will fail only if incorrect
result is returned; FATAL" etc. Right now, AFAIK that hasn't been done.
--
Craig Ringer
--
Tianyin XU,
http://cseweb.ucsd.edu/~tixu/
