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 9E276C7F44A4410D969D25BEDDC2E7FE@amd64
Whole thread Raw
In response to Windowing Function Patch Review -> Standard Conformance  ("David Rowley" <dgrowley@gmail.com>)
Responses Re: Windowing Function Patch Review -> Standard Conformance
List pgsql-hackers
I wrote:
> All,
>
> This is my first patch review for PostgreSQL. I did submit a patch last
> commit fest (Boyer-Moore) so I feel I should review one this commit fest.
> I'm quite new to PostgreSQL so please don't rely on me totally. I'll do my
> best. Heikki is also reviewing this patch which makes me feel better.
>
> My aim is to get the author has much feed back as quickly as possible.
> For this reason I'm going to be breaking down my reviews into the
> following topics.
>
> 1. Does patch apply cleanly?
>
> 2. Any compiler warnings?
>
> 3. Do the results follow the SQL standard?
>
> 4. Performance Comparison, does it perform better than alternate ways of
> doing things. Self joins, sub queries etc.
>
> 5. Performance, no comparison. How does it perform with larger tables?

I regret starting the individual thread for each function now. I was
expecting them to get longer. So I'll use this one for the remainder of the
standard conformance tests.

I covered all of the non-aggregate functions in previous tests. I will do
more final tests on them soon. Tonight I started testing the aggregate
functions with NULLable columns and I've found a small problem. I'll just
post my test script to make it easy for you to see what I mean.

BEGIN WORK;

CREATE TABLE auction_items ( auctionid INT NOT NULL, category VARCHAR(32) NOT NULL, description VARCHAR(128) NOT NULL,
highestbidINT NULL, -- NULL when no bids reserve INT NULL, -- NULL when no reserve started TIMESTAMP NOT NULL, -- When
theaction opened days INT NOT NULL, -- how many days the auction runs.  CHECK(days > 0), PRIMARY KEY (auctionid) 
);

INSERT INTO auction_items VALUES(1,'BIKE','Broken Bicycle',NULL,100,NOW(),10);
INSERT INTO auction_items VALUES(2,'BIKE','Mountain Bike',120,NULL,NOW(),10);
INSERT INTO auction_items VALUES(3,'BIKE','Racer',230,NULL,NOW(),7);

INSERT INTO auction_items VALUES(4,'CAR','Bmw M3',5000,6000,NOW(),7);
INSERT INTO auction_items VALUES(5,'CAR','Audi S3',NULL,6500,NOW(),7);
INSERT INTO auction_items VALUES(6,'CAR','Holden Kingswood',NULL,2000,NOW(),7);

COMMIT;

-- 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.

I've also had a little look at the documentation included in the patch.
At first scan the only thing I can see that is wrong is

+
+    <para>
+     Window functions are put in the <command>SELECT</command> list.
+     It is forbidden anywhere else such as <literal>GROUP BY</literal>,

I think this needs to be rewritten as they are allowed in the ORDER BY
clause, works in patch and spec says the same.

Maybe it should read something more like:

"Window functions are only permitted in the <command>SELECT</command> and
the <command>ORDER BY</command> clause of the query. They are forbidden
anywhere else..." etc.

I won't be around until Monday evening (Tuesday morning JST). I'll pickup
the review again there. It's really time for me to push on with this review.
The patch is getting closer to getting the thumbs up from me. I'm really
hoping that can happen on Monday. Then it's over to Heikki for more code
feedback.

Keep up the good work.

David.







pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Cool hack with recursive queries
Next
From: Grzegorz Jaskiewicz
Date:
Subject: Re: Cool hack with recursive queries