Re: [PERFORM] performance of SELECT * much faster than SELECT colname with large offset

2014-10-03 Thread Marti Raudsepp
On Fri, Oct 3, 2014 at 5:39 AM, Tom Lane t...@sss.pgh.pa.us wrote: Marc Slemko ma...@znep.com writes: I ran into this oddity lately that goes against everything I thought I understood and was wondering if anyone had any insight. SELECT * avoids a projection step ... see

[PERFORM] Planning for Scalability

2014-10-03 Thread Roberto Grandi
Dear Pg people, I would ask for your help considering this scaling issue. We are planning to move from 3Millions of events/day instance of postgres (8 CPU, 65 gb ram) to 5 millions of items/day. What do you suggest in order to plan this switch? Add separate server? Increase RAM? Use SSD? Any

Re: [PERFORM] Planning for Scalability

2014-10-03 Thread k...@rice.edu
On Fri, Oct 03, 2014 at 10:55:04AM +0200, Roberto Grandi wrote: Dear Pg people, I would ask for your help considering this scaling issue. We are planning to move from 3Millions of events/day instance of postgres (8 CPU, 65 gb ram) to 5 millions of items/day. What do you suggest in order

Re: [PERFORM] Planning for Scalability

2014-10-03 Thread Roberto Grandi
Dear All thanks for your precious help. I'll come back to the list once analyzed our system. Roberto - Messaggio originale - Da: k...@rice.edu A: Roberto Grandi roberto.gra...@trovaprezzi.it Cc: pgsql-performance@postgresql.org Inviato: Venerdì, 3 ottobre 2014 15:00:03 Oggetto: Re:

Re: [PERFORM] Planning for Scalability

2014-10-03 Thread Graeme B. Bell
Hi Roberto, Hardware etc. is a solution; but you have not yet characterised the problem. You should investigate if the events are mostly... - reads - writes - computationally intensive - memory intensive - I/O intensive - network I/O intensive - independent? (e.g. does it matter if you

Re: [PERFORM] Planning for Scalability

2014-10-03 Thread Claudio Freire
On Fri, Oct 3, 2014 at 5:55 AM, Roberto Grandi roberto.gra...@trovaprezzi.it wrote: Dear Pg people, I would ask for your help considering this scaling issue. We are planning to move from 3Millions of events/day instance of postgres (8 CPU, 65 gb ram) to 5 millions of items/day. The most

Re: [PERFORM] Yet another abort-early plan disaster on 9.3

2014-10-03 Thread Jeff Janes
On Thu, Oct 2, 2014 at 12:56 PM, Josh Berkus j...@agliodbs.com wrote: On 10/02/2014 02:30 AM, Peter Geoghegan wrote: On Thu, Oct 2, 2014 at 1:19 AM, Simon Riggs si...@2ndquadrant.com wrote: Having read papers on it, I believe the problem is intractable. Coding is not the issue. To anyone:

Re: [PERFORM] Yet another abort-early plan disaster on 9.3

2014-10-03 Thread Tomas Vondra
On 3.10.2014 21:58, Jeff Janes wrote: On Thu, Oct 2, 2014 at 12:56 PM, Josh Berkus j...@agliodbs.com mailto:j...@agliodbs.com wrote: Yes, it's only intractable if you're wedded to the idea of a tiny, fixed-size sample. If we're allowed to sample, say, 1% of the table, we can

Re: [PERFORM] Yet another abort-early plan disaster on 9.3

2014-10-03 Thread Tomas Vondra
On 3.10.2014 02:54, Peter Geoghegan wrote: On Thu, Oct 2, 2014 at 12:56 PM, Josh Berkus j...@agliodbs.com wrote: Yes, it's only intractable if you're wedded to the idea of a tiny, fixed-size sample. If we're allowed to sample, say, 1% of the table, we can get a MUCH more accurate n_distinct