Re: A query that doesn't work on 7.1 - Mailing list pgsql-sql

From Kyle
Subject Re: A query that doesn't work on 7.1
Date
Msg-id 3AA82201.C22A5BAB@actarg.com
Whole thread Raw
In response to A query that doesn't work on 7.1  (Kyle <kyle@actarg.com>)
Responses Re: A query that doesn't work on 7.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
Tom Lane wrote:
> Here's another twist though.  Is this a bug too or is this just beyond our reach?

> psql:lead1.sql:64: ERROR:  Unable to select an aggregate function avg(date)

It's just that we don't have any avg() function for date --- nor for
timestamp, which is a little more surprising.
 

FYI:
I got by with kind of a pseudo average (mean, I guess) for now implemented as:

min(date) + (max(date) - min(date)/2)
 

 
You could probably gin up a usable avg(timestamp) using the avg(float8)
routines, since a timestamp is really just a double under the hood.
 
When you say "gin up" are you talking about C, PL/XXX, or just casts?
 
 

BTW, here's another question:

Here's a view of a union.  The two selects are fast when executed individually (and explain confirms that they use indexes).  When I query the view, though, it is slow (explain says the scans are sequential).

Is this expected or a bug?

-- Simulate a table of lead times
create view vend_v_lead as select
    p.pnum as pnum,'vend' as type,ldtime::float8 as lead,0 as aging from vend_price v, prd_part p where v.pnum = p.pnum
    union select
    p.pnum,'hist',date_part('day',(m.tdate::datetime-m.mtr_date::datetime)::timespan),0 from mtr_reg m, prd_part p where m.pnum = p.pnum and m.ttype = 'po' and m.status = 'clsd'
;
 
 

Attachment

pgsql-sql by date:

Previous
From: David Olbersen
Date:
Subject: explain EXPLAIN?
Next
From: Tom Lane
Date:
Subject: Re: A query that doesn't work on 7.1