Re: [PERFORM] effective_cache_size on 32-bits postgres

cache, so 32 bit pg should not matter. Shared buffers and similar variables will be another matter. Why the heck are you running 32 bit pg on a 64 bit system? You are almost certainly doing it wrong. -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql

Re: [PERFORM] TCP Overhead on Local Loopback

/support/versioning/ -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Hardware advice for scalable warehouse db

. I would steer well clear of SATA unless you are going to be using a fs like ZFS which checksums data. I would hope that a SAN would detect this for you, but I have no idea. -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] Time to put theory to the test?

a crash unsafe product will yield undesirable results when a server crashes. It is also faster for many use cases. InnoDB is crash safe. It is just that simple. -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] Why we don't want hints

with other systems noted? Most other systems have this option so saying They have problems is a giant cop out. -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [PERFORM] Compared MS SQL 2000 to Postgresql 9.0 on Windows

you have a raid card? Is it properly configured? -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] Group commit and commit delay/siblings

be removed? -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Group commit and commit delay/siblings

. Anyway  I would recommended right now to stick with the default and not really use it. It does the sync absorbtion well if you have two many users (though not perfect). Sounds like this setting should go away unless there is a very good reason to keep it. -- Rob Wultsch wult...@gmail.com -- Sent

Re: [PERFORM] BBU Cache vs. spindles

On Wed, Oct 27, 2010 at 6:55 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Oct 27, 2010 at 12:41 AM, Rob Wultsch wult...@gmail.com wrote: On Tue, Oct 26, 2010 at 7:25 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Oct 26, 2010 at 10:13 AM, Rob Wultsch wult...@gmail.com wrote

Re: [PERFORM] BBU Cache vs. spindles

On Tue, Oct 26, 2010 at 5:41 AM, Robert Haas robertmh...@gmail.com wrote: On Fri, Oct 22, 2010 at 3:05 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Rob Wultsch wult...@gmail.com wrote: I would think full_page_writes=off + double write buffer should be far superior, particularly

Re: [PERFORM] BBU Cache vs. spindles

On Tue, Oct 26, 2010 at 7:25 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Oct 26, 2010 at 10:13 AM, Rob Wultsch wult...@gmail.com wrote: The double write buffer is one of the few areas where InnoDB does more IO (in the form of fsynch's) than PG. InnoDB also has fuzzy checkpoints (which

Re: [PERFORM] BBU Cache vs. spindles

to InnodB? -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] BBU Cache vs. spindles

On Fri, Oct 22, 2010 at 10:28 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Rob Wultsch wult...@gmail.com wrote: has PG considered using a double write buffer similar to InnodB? That seems inferior to the full_page_writes strategy, where you only write a page twice the first time

Re: [PERFORM] BBU Cache vs. spindles

On Fri, Oct 22, 2010 at 12:05 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Rob Wultsch wult...@gmail.com wrote: I would think full_page_writes=off + double write buffer should be far superior, particularly given that the WAL is shipped over the network to slaves. For a reasonably

Re: [PERFORM] BBU Cache vs. spindles

On Fri, Oct 22, 2010 at 1:15 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Rob Wultsch wult...@gmail.com wrote: not needing full_page_writes would make geographically dispersed replication possible for certain cases where it is not currently (or at least rather painful). Do you have

Re: [PERFORM] Using more tha one index per table

a look at the page on select for MySQL: http://dev.mysql.com/doc/refman/5.1/en/select.html . If you want a earlier or later version they are easily accessible via a link on the left. -- Rob Wultsch wult...@gmail.com

Re: [PERFORM] Using more tha one index per table

-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance That is not true either, though MySQL is less good at using bitmap'ed indexes. 5.0 can use merge indexes, -- Rob Wultsch wult...@gmail.com

Re: [PERFORM] now() gives same time within the session

table test_time (time timestamp); delete from  test_time; insert into test_time select now(); Use timeofday() instead, now() returns the transaction starting time. Is this part of the SQL standard? -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql

Re: [PERFORM] performance on new linux box

cache policy to write-back? -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] PostgreSQL as a local in-memory cache

not be the same as a user session. -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] performance of temporary vs. regular tables

the Memory table (based on MyISAM) is still somewhat used. -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Random Page Cost and Planner

On Tue, May 25, 2010 at 4:26 PM, David Jarvis thanga...@gmail.com wrote: shared_buffers = 1GB temp_buffers = 32MB work_mem = 32MB maintenance_work_mem = 64MB effective_cache_size = 256MB Shouldn't effective_cache_size be significantly larger? -- Rob Wultsch wult...@gmail.com -- Sent via

Re: [PERFORM] Building multiple indexes concurrently

On Wed, Mar 17, 2010 at 7:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: Greg Smith g...@2ndquadrant.com writes: Rob Wultsch wrote: At a minimum I assume that if both of the commands were started at about the same time they would each scan the table in the same direction and whichever creation

[PERFORM] Building multiple indexes concurrently

would benefit from most of the table data it needed being prepopulated in shared buffers. Is this the case? -- Rob Wultsch wult...@gmail.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref