Re: Does PostgreSQL have complete functional test cases?

Ok, I agree that "2147483647" is not a reasonable setting. But what's the
definition of "reasonable"? I just want to study the impact of the setting
so I test the big number first.

Having the setting:

cpu_index_tuple_cost = 10

I still get failures of "create_index", "inherit", "join", "stats".

When you give users the flexibility of configurations, you cannot say all
the values mismatching with your expectations are not allowed. In fact the
system allowed such settings.

T

On Thu, Nov 8, 2012 at 6:10 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Thu, Nov 8, 2012 at 05:37:22PM -0800, Tianyin Xu wrote:
> > 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.
> > 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.
> >
> > For this particular case, I figured out that it's because of the
> following
> > settings,
> >
> > cpu_index_tuple_cost = 2147483647
> >
> > which assigned a big number to the cpu_index_tuple_cost, affecting the
> query
> > planner.
> >
> > But to me, the configuration settings should not affect the correctness,
> right?
> > Because whatever optimizations you do, the results should be the same
> (what
> > matters is the performance). And that's why I need testing before
> adjusting
> > these values.
>
> We can't test the optimizer is reasonable if you change settings in this
> way, so no, I am not surprised it failed.
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>

--
Tianyin XU,
http://cseweb.ucsd.edu/~tixu/