Re: Current Sources/UW7.1.1
От | Tom Lane |
---|---|
Тема | Re: Current Sources/UW7.1.1 |
Дата | |
Msg-id | 11198.978412572@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Current Sources/UW7.1.1 (Larry Rosenman <ler@lerctr.org>) |
Ответы |
Re: Current Sources/UW7.1.1
|
Список | pgsql-hackers |
Larry Rosenman <ler@lerctr.org> writes: >>>> The planregress.sh tests generate errors. Attached is a tar of the >>>> planregress directory... >> >> Have you examined the diffs to see whether any represent real problems, >> as opposed to trivial changes in output tuple order? > > Is the tuple order differences ok? If so, I believe these were just > order differences, but... Yes, order differences are OK (except for queries that specify an ORDER BY, of course). Most of the regression test scripts are not so pedantic as to use an ORDER BY for every single SELECT, and so their result tuple orderings are not truly well-defined according to the letter of the SQL spec. In practice, since the regress tests start from a virgin database, the planner should choose the same plans on most or all platforms, and so we usually don't have problems with cross-platform differences in result orderings. (There are some tests in which we've had to insert explicit ORDER BY clauses just to prevent such problems, however.) planregress creates an additional source of order variation by forcing different plan types to be used, so you get some "failures" that have to be validated by inspection. We could eliminate these "failures" by adding more explicit ORDER BYs, but IMHO that would actually make planregress less useful, not more. The ORDER BY clauses would push the planner to favor ordered plans over unordered ones, and thus to some extent defeat the purpose of exercising multiple plan types. Since planregress isn't intended for general-purpose use, only as a test tool for planner hacking, I think it's most useful as-is. But you do have to know how to interpret the output. regards, tom lane
В списке pgsql-hackers по дате отправления: