Re: Windowing Function Patch Review -> Standard Conformance - Mailing list pgsql-hackers

From David Rowley
Subject Re: Windowing Function Patch Review -> Standard Conformance
Date
Msg-id 5579A07612624A448C039F833F163A4A@amd64
Whole thread Raw
In response to Re: Windowing Function Patch Review -> Standard Conformance  ("Hitoshi Harada" <umi.tanuki@gmail.com>)
Responses Re: Windowing Function Patch Review -> Standard Conformance  ("Hitoshi Harada" <umi.tanuki@gmail.com>)
Re: Windowing Function Patch Review -> Standard Conformance  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Hitoshi Harada wrote:
> 2008/11/20 David Rowley <dgrowley@gmail.com>:
> > -- The following query gives incorrect results on the
> > -- maxhighbid column
> >
> > SELECT auctionid,
> >       category,
> >       description,
> >       highestbid,
> >       reserve,
> >       MAX(highestbid) OVER (ORDER BY auctionid) AS maxhighbid,
> >       MAX(reserve) OVER() AS highest_reserve
> > FROM auction_items;
> >
> > If you remove the highest_reserve column you get the correct results.
> >
> > The bug also affects MIN, AVG, COUNT, STDDEV but not SUM.
> Good report! I fixed this bug, which was by a trival missuse of
> list_concat() in the planner. This was occurred when the first
> aggregate trans func is strict and the second aggregate argument may
> be null. Yep, the argument of the second was implicitly passed to the
> first wrongly. That's why it didn't occur if you delete the second
> MAX().
>
> I added a test case with the existing data emulating yours (named
> "strict aggs") but if it is wrong, let me know.


It's not quite right yet. I'm also getting regression tests failing on
window. Let me know if you want the diffs.

I've created a query that uses the table in your regression test.
max_salary1 gives incorrect results. If you remove the max_salary2 column it
gives the correct results.

Please excuse the lack of sanity with the query. I had to do it this way to
get 2 columns with NULLs.


SELECT depname,      empno,      salary,      salary1,      salary2,      MAX(salary1) OVER (ORDER BY empno) AS
max_salary1,     MAX(salary2) OVER() AS max_salary2 
FROM (SELECT depname,            empno,            salary,            (CASE WHEN salary < 5000 THEN NULL ELSE salary
END)AS salary1,            (CASE WHEN salary >= 5000 THEN NULL ELSE salary END) AS salary2     FROM empsalary 
) empsalary;

Actual results:
 depname  | empno | salary | salary1 | salary2 | max_salary1 | max_salary2
-----------+-------+--------+---------+---------+-------------+-------------sales     |     1 |   5000 |    5000 |
  |             |        4800personnel |     2 |   3900 |         |    3900 |             |        4800sales     |
3|   4800 |         |    4800 |             |        4800sales     |     4 |   4800 |         |    4800 |             |
      4800personnel |     5 |   3500 |         |    3500 |             |        4800develop   |     7 |   4200 |
|    4200 |             |        4800develop   |     8 |   6000 |    6000 |         |             |        4800develop
|     9 |   4500 |         |    4500 |             |        4800develop   |    10 |   5200 |    5200 |         |
    |        4800develop   |    11 |   5200 |    5200 |         |             |        4800 


Correct results:
 depname  | empno | salary | salary1 | salary2 | max_salary1 | max_salary2
-----------+-------+--------+---------+---------+-------------+-------------sales     |     1 |   5000 |    5000 |
  |        5000 |        4800personnel |     2 |   3900 |         |    3900 |        5000 |        4800sales     |
3|   4800 |         |    4800 |        5000 |        4800sales     |     4 |   4800 |         |    4800 |        5000 |
      4800personnel |     5 |   3500 |         |    3500 |        5000 |        4800develop   |     7 |   4200 |
|    4200 |        5000 |        4800develop   |     8 |   6000 |    6000 |         |        6000 |        4800develop
|     9 |   4500 |         |    4500 |        6000 |        4800develop   |    10 |   5200 |    5200 |         |
6000|        4800develop   |    11 |   5200 |    5200 |         |        6000 |        4800 


This might be a good regression test once it's fixed.

I'm at a bit of a loss to what to do now. Should I wait for your work
Heikki? Or continue validating this patch?

The best thing I can think to do right now is continue and any problems I
find you can add regression tests for, then if we keep your regression tests
for Heikki's changes then we can validate those changes more quickly.

Any thoughts? Better ideas?

David.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: mingw doesn't like PGOPTIONS?
Next
From: Decibel!
Date:
Subject: Re: Simple postgresql.conf wizard