From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
---|---|
To: | David Johnston <polobo(at)yahoo(dot)com> |
Cc: | 'Joel Reymont' <joelr1(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: histogram |
Date: | 2011-04-30 23:35:43 |
Message-ID: | 4DBC9CCF.4030801@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Johnston wrote:
> Given that you are actively implementing the code that uses the 1 and 2 I
> don't see how it is that egregious. When generating calculated fields it is
> cleaner than the alternative:
>
> Select trunc(distance * 10.)/10., count(*)
> From doc_ads
> Group by (trunc(distance * 10.))
> Order by (trunc(distance * 10.))
>
> It would be nice if you could do:
>
> Select trunc(distance * 10.)/10. AS bin, count(*) AS frequency
> From doc_ads
> Group by bin
> Order by bin
>
> But I do not believe that is allowed (though I may have my syntax wrong...)
>
> David J.
>
>
>>> re: 1 and 2. They're horrible (imho) reference to the attributes of the
>>>
> returned tuple. Or at best an exposure of the implementation. :)
>
>
>>> Joel Reymont wrote:
>>>
>>>> I think this should do what I want
>>>>
>>>> select trunc(distance * 10.)/10., count(*)
>>>> from doc_ads
>>>> group by 1 order by 1
>>>>
>>>> Thanks, Joel
>>>>
>
>
I think we're supposed to bottom-post here.
I agree in the case of generated columns and old servers but you see the
practice more commonly than really necessary. But in 8.4 at least
select trunc(distance * 10.0 )/10.0 as histo, count(*) as tally
from d group by histo order by tally;
works just fine for me
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-05-01 03:25:31 | Re: Values larger than 1/3 of a buffer page cannot be indexed (hstore) |
Previous Message | Stefan Keller | 2011-04-30 23:34:33 | Values larger than 1/3 of a buffer page cannot be indexed (hstore) |