Original message
Date: Mon, 25 Jun 2012 12:03:10 -0500
From: pgsql-performance-ow...@postgresql.org (on behalf of Shaun Thomas
stho...@optionshouse.com)
Subject: Re: [PERFORM] MemSQL the world's fastest database?
To: Craig James cja...@emolecules.com
Cc:
Original message
Date: Wed, 24 Aug 2011 11:25:27 -0600
From: pgsql-performance-ow...@postgresql.org (on behalf of David Boreham
david_l...@boreham.org)
Subject: Re: [PERFORM] Intel 320 SSD info
To: pgsql-performance@postgresql.org
On 8/24/2011 11:23 AM, Andy wrote:
Original message
Date: Mon, 15 Aug 2011 19:49:52 -0400
From: pgsql-performance-ow...@postgresql.org (on behalf of Greg Smith
g...@2ndquadrant.com)
Subject: [PERFORM] Reports from SSD purgatory
To: pgsql-performance@postgresql.org pgsql-performance@postgresql.org
News update for
Original message
Date: Wed, 24 Aug 2011 21:32:16 +0200
From: pgsql-performance-ow...@postgresql.org (on behalf of Tomas Vondra
t...@fuzzy.cz)
Subject: Re: [PERFORM] Reports from SSD purgatory
To: gnuo...@rcn.com
Cc: pgsql-performance@postgresql.org
On 24 Srpen 2011, 20:48,
Original message
Date: Wed, 11 May 2011 11:04:49 -0500
From: pgsql-performance-ow...@postgresql.org (on behalf of Shaun Thomas
stho...@peak6.com)
Subject: Re: [PERFORM] Postgres refusing to use 1 core
To: Scott Marlowe scott.marl...@gmail.com
Cc: Craig Ringer
Original message
Date: Wed, 11 May 2011 17:04:50 -0500
From: pgsql-performance-ow...@postgresql.org (on behalf of Shaun Thomas
stho...@peak6.com)
Subject: Re: [PERFORM] Postgres refusing to use 1 core
To: gnuo...@rcn.com
Cc: Scott Marlowe scott.marl...@gmail.com,Craig Ringer
TMS RAMSAN is a DRAM device. TMS built DRAM SSDs going back decades, but have
recently gotten into flash SSDs as well. The DRAM parts are in an order of
magnitude more expensive than others' flash SSDs, gig by gig. Also, about as
fast as off cpu storage gets.
regards,
Robert
Original
Original message
Date: Tue, 26 Apr 2011 09:13:17 -0500
From: pgsql-performance-ow...@postgresql.org (on behalf of J Sisson
sisso...@gmail.com)
Subject: Re: [PERFORM] Time to put theory to the test?
To: Rob Wultsch wult...@gmail.com
Cc: pgsql-performance@postgresql.org
Not for user data, only controller data.
Original message
Date: Wed, 6 Apr 2011 14:11:10 -0700 (PDT)
From: pgsql-performance-ow...@postgresql.org (on behalf of Andy
angelf...@yahoo.com)
Subject: Re: [PERFORM] Intel SSDs that may not suck
To: Merlin Moncure mmonc...@gmail.com,Scott
SSDs have been around for quite some time. The first that I've found is Texas
Memory. Not quite 1977, but not flash either, although they've been doing so
for a couple of years.
http://www.ramsan.com/company/history
Original message
Date: Wed, 06 Apr 2011 20:56:16 -0600
From:
Both the X25-M and the parts that AnandTech reviews (and a pretty thorough one
they do) are, on a good day, prosumer. Getting review material for truly
Enterprise parts, the kind that STEC, Violin, and Texas Memory will spend a
year to get qualified at HP or IBM or Oracle is really hard to
Time for my pet meme to wiggle out of its hole (next to Phil's, and a day
later). For PG to prosper in the future, it has to embrace the
multi-core/processor/SSD machine at the query level. It has to. And it has to
because the Big Boys already do so, to some extent, and they've realized that
Original message
Date: Thu, 3 Feb 2011 18:56:34 +0100
From: pgsql-performance-ow...@postgresql.org (on behalf of Aljoša Mohorović
aljosa.mohoro...@gmail.com)
Subject: Re: [PERFORM] getting the most of out multi-core systems for repeated
complex SELECT statements
To: gnuo...@rcn.com
Original message
Date: Thu, 11 Nov 2010 15:29:40 -0500
From: pgsql-performance-ow...@postgresql.org (on behalf of Robert Haas
robertmh...@gmail.com)
Subject: Re: [PERFORM] anti-join chosen even when slower than old plan
To: Tom Lane t...@sss.pgh.pa.us
Cc: Kevin Grittner
The discussions I've seen indicated that, in use, tablespaces were at the
database level, but, yes, the docs do say that a table can be assigned to a
defined tablespace. What I still can't find is syntax which establishes
buffers/caches/whatever and assigns them to tablespaces. Without that,
Couldn't have said it better myself; covered all the bases. If PG wants to
become an industrial strength database, worthy of replacing DB2/etc., then
these are the sorts of knobs and switches it will need.
-- None of that is anything for amateurs to play with.
Not jam a stick in anybody's
An approach that works can be found in DB2, and likely elsewhere.
The key is that tablespaces/tables/indexes/buffers are all attached through the
bufferpool (the DB2 term). A tablespace/bufferpool match is defined. Then
tables and indexes are assigned to the tablespace (and implicitly, the
I can't tell if you meant for this to be insulting or my reading it that way is
wrong, but it certainly wasn't put in a helpful tone. Let me summarize for
you. You've been told that putting ORDER BY into a view is a generally poor
idea anyway, that it's better to find ways avoid this class of
Original message
Date: Wed, 22 Sep 2010 20:54:22 -0400
From: pgsql-performance-ow...@postgresql.org (on behalf of Robert Haas
robertmh...@gmail.com)
Subject: Re: [PERFORM] Useless sort by
To: Gaetano Mendola mend...@gmail.com
Cc: Tom Lane
I may be a little bit over-sensitive on the topic, because I've seen
so many people who consider it wrong to use natural keys on any
table *ever*. About one out of every four or five programmers who
gets hired here feels compelled to argue that we should add
surrogate keys to all our tables for
If you can cite a specific device that draws more than 10% of the equivalently
performing (e.g., short stroked) array, I would be very interested. There may
be a DRAM SSD that draws more than a flash SSD, but I'd be really surprised to
find a flash SSD that draws the same as any HDD, even at
Here's a quote from the docs:
To combine multiple indexes, the system scans each needed index and prepares a
bitmap in memory giving the locations of table rows that are reported as
matching that index's conditions. The bitmaps are then ANDed and ORed together
as needed by the query. Finally,
A number of amusing aspects to this discussion.
- I've carried out similar tests using the Intel X-25M with both PG and DB2
(both on linux). While it is a simple matter to build parallel databases on
DB2, on HDD and SSD, with buffers and tablespaces and logging and on and on set
to recreate
23 matches
Mail list logo
