From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kyle <kyle(at)actarg(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: A query that doesn't work on 7.1 |
Date: | 2001-03-09 00:39:23 |
Message-ID: | 3064.984098363@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Kyle <kyle(at)actarg(dot)com> writes:
>> 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?
I was thinking of full-scale cheating: make a new pg_aggregate entry for
avg(timestamp) that points at the existing pg_proc entries that support
avg(float8). CREATE AGGREGATE won't do this for you, but there's always
good old INSERT INTO ...
> 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?
Seems odd. Need enough info to reproduce, please?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ken Kline | 2001-03-09 04:52:44 | perl dbd |
Previous Message | Kyle | 2001-03-09 00:21:22 | Re: A query that doesn't work on 7.1 |