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 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 estimate usi

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 > 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 mo

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 wrote: > On 10/02/2014 02:30 AM, Peter Geoghegan wrote: > > On Thu, Oct 2, 2014 at 1:19 AM, Simon Riggs > wrote: > >> Having read papers on it, I believe the problem is intractable. Coding > >> is not the issue. To anyone: please prove me wrong, in de

Re: [PERFORM] Planning for Scalability

2014-10-03 Thread Claudio Freire
On Fri, Oct 3, 2014 at 5:55 AM, 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. The most important hardware part the

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 split

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" Cc: pgsql-performance@postgresql.org Inviato: Venerdì, 3 ottobre 2014 15:00:03 Oggetto: Re: [PERFORM] Planning for Scalabil

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 or

[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 r

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

2014-10-03 Thread Marti Raudsepp
On Fri, Oct 3, 2014 at 5:39 AM, Tom Lane wrote: > Marc Slemko 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 ExecAssignScanProjectionInfo. It would be cool