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 as
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,
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 gr
>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
Original message
>Date: Wed, 22 Sep 2010 20:54:22 -0400
>From: pgsql-performance-ow...@postgresql.org (on behalf of Robert Haas
>)
>Subject: Re: [PERFORM] Useless sort by
>To: Gaetano Mendola
>Cc: Tom Lane ,pgsql-performance@postgresql.org
>
>On Mon, Sep 13, 2010 at 1:09 PM, Gaetano
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
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
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, I
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 ey
Original message
>Date: Thu, 11 Nov 2010 15:29:40 -0500
>From: pgsql-performance-ow...@postgresql.org (on behalf of Robert Haas
>)
>Subject: Re: [PERFORM] anti-join chosen even when slower than old plan
>To: Tom Lane
>Cc: Kevin Grittner ,Mladen Gogala
>,"pgsql-performance@postgresql.
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ć
>)
>Subject: Re: [PERFORM] getting the most of out multi-core systems for repeated
>complex SELECT statements
>To: gnuo...@rcn.com
>Cc: pgsql-performan
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 come
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
>)
>Subject: Re: [PERFORM] Intel SSDs that may not suck
>To: Merlin Moncure ,Scott Carey
>Cc: "pgsql-performance@po
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: pg
Original message
>Date: Tue, 26 Apr 2011 09:13:17 -0500
>From: pgsql-performance-ow...@postgresql.org (on behalf of J Sisson
>)
>Subject: Re: [PERFORM] Time to put theory to the test?
>To: Rob Wultsch
>Cc: "pgsql-performance@postgresql.org"
>
>On Mon, Apr 25, 2011 at 10:04 PM, Rob
Fusion SSDs install on PCIe slots, so are limited by slot count. None, so far
as I recall, are bootable (although Fusion has been promising that for more
than a year). If you've a BCNF schema of moderate size, then any SSD as
primary store is a good option; Fusion's are just even faster. If y
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 m
Original message
>Date: Wed, 11 May 2011 11:04:49 -0500
>From: pgsql-performance-ow...@postgresql.org (on behalf of Shaun Thomas
>)
>Subject: Re: [PERFORM] Postgres refusing to use >1 core
>To: Scott Marlowe
>Cc: Craig Ringer ,Aren Cambre
>,
>
>On 05/10/2011 11:26 PM, Scott Marlowe w
Original message
>Date: Wed, 11 May 2011 17:04:50 -0500
>From: pgsql-performance-ow...@postgresql.org (on behalf of Shaun Thomas
>)
>Subject: Re: [PERFORM] Postgres refusing to use >1 core
>To:
>Cc: Scott Marlowe ,Craig Ringer
>,Aren Cambre
>,
>
>On 05/11/2011 02:53 PM, gnuo...@rcn.
Original message
>Date: Wed, 24 Aug 2011 11:25:27 -0600
>From: pgsql-performance-ow...@postgresql.org (on behalf of David Boreham
>)
>Subject: Re: [PERFORM] Intel 320 SSD info
>To: pgsql-performance@postgresql.org
>
> On 8/24/2011 11:23 AM, Andy wrote:
>
> According to the spec
Original message
>Date: Mon, 15 Aug 2011 19:49:52 -0400
>From: pgsql-performance-ow...@postgresql.org (on behalf of Greg Smith
>)
>Subject: [PERFORM] Reports from SSD purgatory
>To: "pgsql-performance@postgresql.org"
>
>News update for anyone else who's trapped like me, waiting for
Original message
>Date: Wed, 24 Aug 2011 21:32:16 +0200
>From: pgsql-performance-ow...@postgresql.org (on behalf of "Tomas Vondra"
>)
>Subject: Re: [PERFORM] Reports from SSD purgatory
>To: gnuo...@rcn.com
>Cc: pgsql-performance@postgresql.org
>
>On 24 Srpen 2011, 20:48, gnuo...@rcn.
Original message
>Date: Mon, 25 Jun 2012 12:03:10 -0500
>From: pgsql-performance-ow...@postgresql.org (on behalf of Shaun Thomas
>)
>Subject: Re: [PERFORM] MemSQL the "world's fastest database"?
>To: Craig James
>Cc:
>
>On 06/25/2012 11:25 AM, Craig James wrote:
>
>> Any thoughts a
24 matches
Mail list logo
