Re: [PERFORM] extremly bad select performance on huge table

Hi Kevin, this is what I need (I think). Hopefully a cursor can operate on a join. Will read docu now. Thanks! Björn Am 22.10.2014 16:53, schrieb Kevin Grittner: Björn Wittich wrote: I do not want the db server to prepare the whole query result at once, my intention is that the asynch

Re: [PERFORM] extremly bad select performance on huge table

Björn Wittich wrote: > I do not want the db server to prepare the whole query result at > once, my intention is that the asynchronous retrieval starts as > fast as possible. Then you probably should be using a cursor. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL

Re: [PERFORM] extremly bad select performance on huge table

-Original Message- From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Björn Wittich Sent: Wednesday, October 22, 2014 1:06 AM To: pgsql-performance@postgresql.org Subject: Re: [PERFORM] extremly bad select performance on huge table

Re: [PERFORM] Query with large number of joins

On Tue, Oct 21, 2014 at 11:50 AM, Tom Lane wrote: > Marco Di Cesare writes: >> COUNT(DISTINCT "foxtrot_india"."bravo_romeo") > > Ah. That explains why the planner doesn't want to use a hash aggregation > step --- DISTINCT aggregates aren't supported with those. yup. With this q