Re: [PERFORM] Unexpected pgbench result

2013-12-20 Thread Shaun Thomas
On 12/19/2013 04:06 PM, Dave Johansen wrote: Right now, we're running a RAID 1 for pg_clog, pg_log and pg_xlog and then a RAID 1+0 with 12 disks for the data. Would there be any benefit to running a separate RAID 1+0 with a tablespace for the indexes? Not really. PostgreSQL doesn't currently

Re: [PERFORM] Regarding Hardware Tuning

2013-12-20 Thread Shaun Thomas
On 12/19/2013 06:37 PM, Scott Marlowe wrote: The ebook edition is on sale for $5.00 which is a STEAL. Wow, I guess I should pay better attention to all those annoying emails Packt sends me. That'll make a good portable copy since I tend to keep the real version on my bookshelf at home. :)

Re: [PERFORM] slow query - will CLUSTER help?

2013-12-20 Thread Shaun Thomas
On 12/19/2013 03:24 PM, Sergey Konoplev wrote: 2. You are limited with IO I would also suggest you to upgrade your storage in this case. I think this is the case. If I recall correctly, his setup includes a single RAID-1 for everything, and he only has 32GB of RAM. In fact, the WAL traffic

Re: [PERFORM] Unexpected pgbench result

2013-12-20 Thread Dave Johansen
On Fri, Dec 20, 2013 at 7:10 AM, Shaun Thomas stho...@optionshouse.comwrote: On 12/19/2013 04:06 PM, Dave Johansen wrote: Right now, we're running a RAID 1 for pg_clog, pg_log and pg_xlog and then a RAID 1+0 with 12 disks for the data. Would there be any benefit to running a separate RAID

Re: [PERFORM] Unexpected pgbench result

2013-12-20 Thread Kevin Grittner
Dave Johansen davejohan...@gmail.com wrote: Is there a benefit to having the WAL and logs on the separate RAID 1? Or is just having them be part of the larger RAID 1+0 just as good? I once accidentally left the pg_xlog directory on the 40-spindle RAID with most of the data instead of moving

Re: [PERFORM] Unexpected pgbench result

2013-12-20 Thread Dave Johansen
On Fri, Dec 20, 2013 at 8:22 AM, Kevin Grittner kgri...@ymail.com wrote: Dave Johansen davejohan...@gmail.com wrote: Is there a benefit to having the WAL and logs on the separate RAID 1? Or is just having them be part of the larger RAID 1+0 just as good? I once accidentally left the

Re: [PERFORM] Recommendations for partitioning?

2013-12-20 Thread Dave Johansen
On Thu, Dec 19, 2013 at 10:27 AM, Scott Marlowe scott.marl...@gmail.comwrote: On Thu, Dec 19, 2013 at 9:53 AM, Dave Johansen davejohan...@gmail.com wrote: On Sat, Dec 7, 2013 at 1:37 PM, Scott Marlowe scott.marl...@gmail.com wrote: I'll add that you can use assymetric partitioning if

Re: [PERFORM] Recommendations for partitioning?

2013-12-20 Thread bricklen
On Fri, Dec 20, 2013 at 7:52 AM, Dave Johansen davejohan...@gmail.comwrote: It would be nice if there was just a move command, but that seems like the type of model that we want and we'll probably move to that. I haven't been following this thread, but this comment caught my eye. Are you

Re: [PERFORM] slow query - will CLUSTER help?

2013-12-20 Thread Shaun Thomas
On 12/20/2013 09:57 AM, Sev Zaslavsky wrote: There is a separate RAID-1 for WAL, another for tablespace and another for operating system. I tend to stick to DB-size / 10 as a minimum, but I also have an OLTP system. For a more OLAP-type, the ratio is negotiable. The easiest way to tell is

Re: [PERFORM] Recommendations for partitioning?

2013-12-20 Thread Alvaro Herrera
Dave Johansen escribió: On Thu, Dec 19, 2013 at 10:27 AM, Scott Marlowe scott.marl...@gmail.comwrote: That's pretty much it. What I did was to create the new month table and day tables, alter my triggers to reflect this, then move the data with insert into / select from query for each

Re: [PERFORM] Recommendations for partitioning?

2013-12-20 Thread Shaun Thomas
On 12/20/2013 09:59 AM, Alvaro Herrera wrote: WITH moved AS ( DELETE FROM src WHERE .. RETURNING * ) INSERT INTO dst SELECT * FROM moved; I know that's effectively an atomic action, but I'd feel a lot more comfortable reversing that logic so the delete is based on the results

Re: [PERFORM] Recommendations for partitioning?

2013-12-20 Thread Dave Johansen
On Fri, Dec 20, 2013 at 9:18 AM, Shaun Thomas stho...@optionshouse.comwrote: On 12/20/2013 09:59 AM, Alvaro Herrera wrote: WITH moved AS ( DELETE FROM src WHERE .. RETURNING * ) INSERT INTO dst SELECT * FROM moved; I know that's effectively an atomic action, but I'd feel

Re: [PERFORM] Recommendations for partitioning?

2013-12-20 Thread Dave Johansen
On Fri, Dec 20, 2013 at 8:52 AM, Dave Johansen davejohan...@gmail.comwrote: On Thu, Dec 19, 2013 at 10:27 AM, Scott Marlowe scott.marl...@gmail.comwrote: On Thu, Dec 19, 2013 at 9:53 AM, Dave Johansen davejohan...@gmail.com wrote: On Sat, Dec 7, 2013 at 1:37 PM, Scott Marlowe

Re: [PERFORM] slow query - will CLUSTER help?

2013-12-20 Thread Gavin Flower
On 21/12/13 05:11, Shaun Thomas wrote: [...] . Of course, don't forget to buy modules in multiples of four, otherwise you're not taking advantage of all the CPU's memory channels. :) Note some processors have 3 (three) memory channels! And I know of some with 4 memory channels. So it is

Re: [PERFORM] DATE_TRUNC() and GROUP BY?

2013-12-20 Thread David Rowley
On Fri, Dec 20, 2013 at 1:35 PM, Dave Johansen davejohan...@gmail.comwrote: I just ran into an interesting issue on Postgres 8.4. I have a database with about 3 months of data and when I do following query: SELECT DATE_TRUNC('day', time) AS time_t, COUNT(*) FROM mytable GROUP BY time_t;