Re: [PERFORM] FUSION-IO io cards

I was referring to those. Of course, they may be more expensive than FusionIO. You get what you pay for (in this case). -- Joachim Worringen Senior Performance Architect International Algorithmic Trading GmbH -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] FUSION-IO io cards

probably because some software-based house-keeping needs to be done. -- Joachim Worringen Senior Performance Architect International Algorithmic Trading GmbH -- 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] Which RAID Controllers to pick/avoid?

Am 03.02.2011 07:45, schrieb Magnus Hagander: On Thu, Feb 3, 2011 at 07:30, Dan Birken wrote: - Is the linux support of the LSI and Adaptec cards comparable? Can't comment on that one, sorry. We dropped LSI in favour of Adaptec for exactly this reason. We run hundreds of machines in remote

[PERFORM] optimal ZFS filesystem on JBOD layout

Greetings, we are running a few databases of currently 200GB (growing) in total for data warehousing: - new data via INSERTs for (up to) millions of rows per day; sometimes with UPDATEs - most data in a single table (=> 10 to 100s of millions of rows) - queries SELECT subsets of this table via

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

Am 02.06.2010 12:03, schrieb Pierre C: Usually WAL causes a much larger performance hit than this. Since the following command : CREATE TABLE tmp AS SELECT n FROM generate_series(1,100) AS n which inserts 1M rows takes 1.6 seconds on my desktop, your 800k rows INSERT taking more than 3 min

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

On 05/26/2010 06:03 PM, Joachim Worringen wrote: Am 25.05.2010 12:41, schrieb Andres Freund: On Tuesday 25 May 2010 11:00:24 Joachim Worringen wrote: Thanks. So, the Write-Ahead-Logging (being used or not) does not matter? It does matter quite significantly in my experience. Both from an io

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

Am 25.05.2010 12:41, schrieb Andres Freund: On Tuesday 25 May 2010 11:00:24 Joachim Worringen wrote: Thanks. So, the Write-Ahead-Logging (being used or not) does not matter? It does matter quite significantly in my experience. Both from an io and a cpu overhead perspective. O.k., looks as if

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

Am 25.05.2010 11:38, schrieb Grzegorz Jaśkiewicz: WAL does the same thing to DB journaling does to the FS. Plus allows you to roll back (PITR). As for the RAM, it will be in ram as long as OS decides to keep it in RAM cache, and/or its in the shared buffers memory. Or until I commit the transa

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

Am 25.05.2010 11:15, schrieb Thom Brown: 2010/5/25 Joachim Worringen: And, is there anything like RAM-only tables? I really don't care whether the staging data is lost on the rare event of a machine crash, or whether the query crashes due to lack of memory (I make sure there's enough

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

Am 25.05.2010 10:49, schrieb Grzegorz Jaśkiewicz: temporary tables are handled pretty much like the regular table. The magic happens on schema level, new schema is setup for connection, so that it can access its own temporary tables. Temporary tables also are not autovacuumed. And that's pretty m

[PERFORM] performance of temporary vs. regular tables

Greetings, in http://archives.postgresql.org/message-id/1056648218.7041.11.ca...@jester, it is stated that the performance of temporary tables is "the same as a regular table but without WAL on the table contents.". I have a datamining-type application which makes heavy use of temporary tab