On 01/15/2011 12:54 AM, Mladen Gogala wrote:
Craig Ringer wrote:
On 01/12/2011 10:16 PM, Guillaume Cottenceau wrote:
What's your point and in what is it related to that ML?
Given the package names, I suspect this is a poorly-expressed
complaint about the performance of downloads from the pgd
> After trying both against the real tables DISTINCT ON seems to be
> about two orders of magnitude faster than the other options.
Glad it worked. It looked at least naively similar to situations I've run into
and DISTINCT ON always helped me out. It's all the fun of GROUP BY with the
ability t
> Shaun's example is a bit off: normally, when using DISTINCT ON, you want
> an ORDER BY key that uses all the given DISTINCT keys and then some
> more. To get the max revision for each a/b combination it ought to be
Hah, well i figured I was doing something wrong. I just thought about it a
lit
On Fri, Jan 14, 2011 at 2:11 PM, Jon Nelson wrote:
> On Thu, Jan 13, 2011 at 6:10 PM, Tom Lane wrote:
>> Jon Nelson writes:
>>> On Thu, Jan 13, 2011 at 5:05 PM, Tom Lane wrote:
If you have enough memory to de-dup them individually, you surely have
enough to de-dup all at once.
>>
>>>
Hi there,
Could someone please tell me why the following query won't work
select DISTINCT get_unit(unit) as unit, get_ingredient(ing) as ing,
get_ing_aisle(1,ing) as aisle
from recipe_ing where recipe in(1084, 1086, 1012, 618) and qtydec>0 and ing not
in(select ing from excluded_ing where own
On 01/15/2011 12:54 AM, Mladen Gogala wrote:
Yes, it was a complaint about the download speed.
- Information abut their local connectivity
- mtr --report / traceroute output
- tests from other available hosts
OK, that's one out of three. How about the other two?
15 gayrettepe-t3-1-gayrette
