From: | "David Johnston" <polobo(at)yahoo(dot)com> |
---|---|
To: | "'Rob Sargent'" <robjsargent(at)gmail(dot)com>, "'Joel Reymont'" <joelr1(at)gmail(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: histogram |
Date: | 2011-04-30 21:41:52 |
Message-ID: | 02a801cc077f$6bca68d0$435f3a70$@yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Keller | 2011-04-30 23:34:33 | Values larger than 1/3 of a buffer page cannot be indexed (hstore) |
Previous Message | Dimitri Fontaine | 2011-04-30 19:56:48 | Re: [HACKERS] PostgreSQL Core Team |