[PERFORM] Fast HashJoin only after a cluster/recreate table

2016-03-31 Thread Alexandre de Arruda Paes
Hi, In the query below, the planner choose an extreme slow mergejoin(380 seconds). 'Vacuum analyze' can't help. If I CLUSTER (or recreate) table ES09T1, the planner choose a faster hashjoin (about 10 seconds). But, obviously, I can't do that with the users connected. After some time after cluster(

Re: [PERFORM] Big number of connections

2016-03-31 Thread Karl Denninger
On 3/31/2016 17:47, Alvaro Herrera wrote: > Andrew Dunstan wrote: > >> On 03/31/2016 03:12 PM, Igor Neyman wrote: We are going to build system based on PostgreSQL database for huge number of individual users (few thousands). Each user will have his own account, for authorization

Re: [PERFORM] Big number of connections

2016-03-31 Thread Chris Cogdon
Although somewhat academic, since pgboucer doesn’t support it (and might not ever), have a look at this ticket which, if it was ever supported, would give you what you needed: https://github.com/pgbouncer/pgbouncer/issues/75 > On Mar 31, 2016

Re: [PERFORM] Big number of connections

2016-03-31 Thread Alvaro Herrera
Andrew Dunstan wrote: > On 03/31/2016 03:12 PM, Igor Neyman wrote: > > > We are going to build system based on PostgreSQL database for huge > > > number of individual users (few thousands). Each user will have his own > > > account, for authorization we will use Kerberos (MIT or Windows). > >

Re: [PERFORM] Big number of connections

2016-03-31 Thread Andrew Dunstan
On 03/31/2016 03:12 PM, Igor Neyman wrote: -Original Message- From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Jarek Sent: Thursday, March 31, 2016 3:08 PM To: pgsql-performance@postgresql.org Subject: [PERFORM] Big number of con

Re: [PERFORM] Big number of connections

2016-03-31 Thread Igor Neyman
-Original Message- From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Jarek Sent: Thursday, March 31, 2016 3:08 PM To: pgsql-performance@postgresql.org Subject: [PERFORM] Big number of connections Hello! We are going to buil

[PERFORM] Big number of connections

2016-03-31 Thread Jarek
Hello! We are going to build system based on PostgreSQL database for huge number of individual users (few thousands). Each user will have his own account, for authorization we will use Kerberos (MIT or Windows). Most of users will have low activity, but for various reasons, connection sho

Re: [PERFORM] Adding a ROLLUP switches to GroupAggregate unexpectedly

2016-03-31 Thread k...@rice.edu
On Thu, Mar 31, 2016 at 02:56:48PM -0400, Tom Lane wrote: > Chris Cogdon writes: > > Hi folks! I’ve a query where adding a rollup to the group by switches to > > GroupAggregate unexpectedly, where the standard GROUP BY uses > > HashAggregate. > > The current implementation of rollup doesn't suppo

Re: [PERFORM] Adding a ROLLUP switches to GroupAggregate unexpectedly

2016-03-31 Thread Tom Lane
Chris Cogdon writes: > Hi folks! I’ve a query where adding a rollup to the group by switches to > GroupAggregate unexpectedly, where the standard GROUP BY uses > HashAggregate. The current implementation of rollup doesn't support using hashed aggregation. I don't know if that's for lack of rou

[PERFORM] Adding a ROLLUP switches to GroupAggregate unexpectedly

2016-03-31 Thread Chris Cogdon
Hi folks! I’ve a query where adding a rollup to the group by switches to GroupAggregate unexpectedly, where the standard GROUP BY uses HashAggregate. Since the rollup should only add one additional bucket, the switch to having to sort (and thus a to-disk temporary file) is very puzzling. This re