On 3/26/09 2:44 PM, "Scott Carey" wrote:
>
>
> On 3/25/09 9:43 PM, "Mark Kirkwood" wrote:
>
>> Stef Telford wrote:
>>>
>>> Hello Mark,
>>> Okay, so, take all of this with a pinch of salt, but, I have the
>>> same config (pretty much) as you, with checkpoint_Segments raised to
>>> 192. T
On 3/25/09 9:28 PM, "Mark Kirkwood" wrote:
> I wrote:
>> Scott Marlowe wrote:
>>
>>>
>>> Can you try changing the chunksize on the test box you're testing on
>>> to see if that helps?
>>>
>>>
>>
>> Yes - or I am hoping to anyway (part of posting here was to collect
>> some outside validati
On 3/25/09 9:43 PM, "Mark Kirkwood" wrote:
> Stef Telford wrote:
>>
>> Hello Mark,
>> Okay, so, take all of this with a pinch of salt, but, I have the
>> same config (pretty much) as you, with checkpoint_Segments raised to
>> 192. The 'test' database server is Q8300, 8GB ram, 2 x 7200rpm SA
On Thu, 26 Mar 2009, Mark Kirkwood wrote:
Also, if you want to minimize total I/O, you might drop
bgwriter_lru_maxpages to 0. That feature presumes you have some spare I/O
capacity you use to prioritize lower latency, and it sounds like you don't.
You get the lowest total I/O per transaction
On Thu, 26 Mar 2009, Tom Lane wrote:
No, it doesn't. Have you thought about coding it in plpgsql?
*Looks* Nice.
So, it looks like I would be able to write a plpgsql function that returns
a table equivalent to the query I posted earlier. However, I'd like to
eat my cake *and* have it. My int
Matthew Wakeling writes:
> This query takes about two hours.
> Now, it happens that there is an algorithm for calculating overlaps which
> is really quick. It involves iterating through the table in order of the
> start variable and keeping a list of ranges which "haven't ended yet".
> When yo
Matthew Wakeling wrote:
> any other tips?
I would try adding an index on (objectid, start) and another on
(objectid, end) and see how that first query does. Also, if id is a
unique identifier, I'd recommend a unique constraint or (better) a
primary key definition. Check the system tables to s
So, I have an query that has a very great difference between the possible
performance and the achieved performance. I was wondering if there was a
possibility that Postgres would approach the possible performance by some
devious method.
The query returns a list of overlaps between objects. E
We have a box outfitted with two of them we are testing. We are testing with
VxFS and ext3, but not quite ready to publish. I will reply when we are done.
-Original Message-
From: pgsql-performance-ow...@postgresql.org on behalf of Dave Cramer
Sent: Thu 3/26/2009 5:47 AM
To: pgsql-pe
XFS
- Luke
From: pgsql-performance-ow...@postgresql.org
To: pgsql-performance@postgresql.org
Sent: Thu Mar 26 05:47:55 2009
Subject: [PERFORM] I have a fusion IO drive available for testing
So far using dd I am seeing around 264MB/s on ext3, 335MB/s on ext2 wr
So far using dd I am seeing around 264MB/s on ext3, 335MB/s on ext2 write
speed. So the question becomes what is the best filesystem for this drive?
Anyone want me to run anything on it ?
Dave
11 matches
Mail list logo
