Your results are consistent with the benchmarks I've seen. Intel SSD have much
worse write performance compared to SSD that uses Sandforce controllers, which
Vertex 2 Pro does.
According to this benchmark, at high queue depth the random write performance
of Sandforce is more than 5 times that o
On Wed, Nov 2, 2011 at 3:53 PM, CS DBA wrote:
> On 11/02/2011 02:45 PM, Scott Marlowe wrote:
>>
>> On Wed, Nov 2, 2011 at 2:21 PM, CS DBA wrote:
>>>
>>> Hi All;
>>>
>>> The below contab2 table conmtains ~400,000 rows. This query should not
>>> take
>>> this long. We've tweaked work_mem up to 50M
On 03/11/11 09:12, Brian Fehrle wrote:
And here is a query plan.
Hash Join (cost=17516.470..26386.660 rows=27624 width=4) (actual
time=309.194..395.135 rows=12384 loops=1)
Hash Cond: (yankee.alpha = hotel_zulu.quebec)
-> Bitmap Heap Scan on yankee (cost=1066.470..8605.770 rows=2762
Thanks Tom,
And looks like I pasted an older explain plan, which is almost exactly
the same as the one with 50MB work_mem, except for the hash join
'buckets' part which used more memory and only one 'bucket' so to speak.
When running with the 50MB work_mem over 1MB work_mem, the query went
fr
Brian Fehrle writes:
> I've got a query that I need to squeeze as much speed out of as I can.
Hmm ... are you really sure this is being run with work_mem = 50MB?
The hash join is getting "batched", which means the executor thinks it's
working under a memory constraint significantly less than the
On 11/02/2011 02:45 PM, Scott Marlowe wrote:
On Wed, Nov 2, 2011 at 2:21 PM, CS DBA wrote:
Hi All;
The below contab2 table conmtains ~400,000 rows. This query should not take
this long. We've tweaked work_mem up to 50MB, ensured that the appropriate
indexes are in place, etc...
Thoughts?
Th
On Wed, Nov 2, 2011 at 3:45 PM, Yeb Havinga wrote:
> On 2011-11-02 16:16, Yeb Havinga wrote:
>>
>> On 2011-11-02 15:26, Merlin Moncure wrote:
>>
>>> I would keep at least 20-30% of both drives unpartitioned to leave the
>>> controller room to wear level and as well as other stuff. I'd try
>>> wip
On Wed, Nov 2, 2011 at 2:21 PM, CS DBA wrote:
> Hi All;
>
> The below contab2 table conmtains ~400,000 rows. This query should not take
> this long. We've tweaked work_mem up to 50MB, ensured that the appropriate
> indexes are in place, etc...
>
> Thoughts?
>
> Thanks in advance
How long should
On 2011-11-02 16:16, Yeb Havinga wrote:
On 2011-11-02 15:26, Merlin Moncure wrote:
I would keep at least 20-30% of both drives unpartitioned to leave the
controller room to wear level and as well as other stuff. I'd try
wiping the drives, reparititoing, and repeating your test. I would
also c
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: Wednesday, November 02, 2011 11:13 AM
> To: Tom Lane
> Cc: Jay Levitt; pgsql-performance@postgresql.org
> Subject: Re: Guide to PG's capabilities for inlining, predicate
> hoisting, flattening, etc?
> ...
Hi All;
The below contab2 table conmtains ~400,000 rows. This query should not
take this long. We've tweaked work_mem up to 50MB, ensured that the
appropriate indexes are in place, etc...
Thoughts?
Thanks in advance
Explain analyze:
SELECT contab2.contacts_tab
FROM contab2
INNER JOIN scta
Hi all,
I've got a query that I need to squeeze as much speed out of as I can.
When I execute this query, the average time it takes is about 190 ms. I
increased my work_mem from 1 MB to 50MB and it decreased the timing down
to an average of 170 ms, but that's still not fast enough. This query
On 11/2/11 10:22 AM, Claudio Freire wrote:
On Wed, Nov 2, 2011 at 12:13 PM, Robert Haas wrote:
I wonder if we need to rethink, though. We've gotten a number of
reports of problems that were caused by single-use CTEs not being
equivalent - in terms of performance - to a non-CTE formulation of t
On Wed, Nov 2, 2011 at 10:16 AM, Yeb Havinga wrote:
> On 2011-11-02 15:26, Merlin Moncure wrote:
>>
>> On Wed, Nov 2, 2011 at 8:05 AM, Yeb Havinga wrote:
>>>
>>> Hello list,
>>>
>>> A OCZ Vertex 2 PRO and Intel 710 SSD, both 100GB, in a software raid 1
>>> setup. I was pretty convinced this was t
On Wed, Nov 2, 2011 at 12:13 PM, Robert Haas wrote:
> I wonder if we need to rethink, though. We've gotten a number of
> reports of problems that were caused by single-use CTEs not being
> equivalent - in terms of performance - to a non-CTE formulation of the
> same idea. It seems necessary for
On Wednesday 02 Nov 2011 16:13:09 Robert Haas wrote:
> On Wed, Nov 2, 2011 at 10:38 AM, Tom Lane wrote:
> > Jay Levitt writes:
> >> So you can see where I'm going. I know if I break everything into
> >> elegant, composable functions, it'll continue to perform poorly. If I
> >> write one big hai
So the Intel 710 kind of sucks latency wise. Is it because it is also
heavily reading, and maybe WAL should not be put on it?
A couple quick thoughts:
1. There are a lot of moving parts in the system besides the SSDs.
It will take some detailed analysis to determine the cause for the
outlyi
On 2011-11-02 15:26, Merlin Moncure wrote:
On Wed, Nov 2, 2011 at 8:05 AM, Yeb Havinga wrote:
Hello list,
A OCZ Vertex 2 PRO and Intel 710 SSD, both 100GB, in a software raid 1
setup. I was pretty convinced this was the perfect solution to run
PostgreSQL on SSDs without a IO controller with BB
On Wed, Nov 2, 2011 at 10:38 AM, Tom Lane wrote:
> Jay Levitt writes:
>> So you can see where I'm going. I know if I break everything into
>> elegant, composable functions, it'll continue to perform poorly. If I
>> write one big hairy, it'll perform great but it will be difficult to
>> maintain
On Wed, Nov 2, 2011 at 16:04, Yeb Havinga wrote:
> On 2011-11-02 15:06, Kevin Grittner wrote:
>>
>> Yeb Havinga wrote:
>>
>>> I'm now contemplating not using the 710 at all. Why should I not
>>> buy two 6Gbps SSDs without supercap (e.g. Intel 510 and OCZ Vertex
>>> 3 Max IOPS) with a IO controlle
On 2011-11-02 15:06, Kevin Grittner wrote:
Yeb Havinga wrote:
I'm now contemplating not using the 710 at all. Why should I not
buy two 6Gbps SSDs without supercap (e.g. Intel 510 and OCZ Vertex
3 Max IOPS) with a IO controller+BBU?
Wouldn't the data be subject to loss between the time the IO
Jay Levitt writes:
> So you can see where I'm going. I know if I break everything into
> elegant, composable functions, it'll continue to perform poorly. If I
> write one big hairy, it'll perform great but it will be difficult to
> maintain, and it will be inelegant and a kitten will die. My to
Mohamed Hashim writes:
> The below are the sample query which i put for particular one bill_id
> EXPLAIN ANALYZE SELECT abd.bill_no as
> bill_no,to_char(abd.bill_date,'dd/mm/') AS date,mp.product_desc as
> product_desc,std.quantity,std.area,rip.price AS rate
> FROM acc_bill_items_106 abi
>
On Wed, Nov 2, 2011 at 8:05 AM, Yeb Havinga wrote:
> Hello list,
>
> A OCZ Vertex 2 PRO and Intel 710 SSD, both 100GB, in a software raid 1
> setup. I was pretty convinced this was the perfect solution to run
> PostgreSQL on SSDs without a IO controller with BBU. No worries for strange
> firmware
As I've come up to speed on SQL and PostgreSQL with some
medium-complexity queries, I've asked a few questions about what the
optimizer will do in various situations. I'm not talking about the
seq-scan-vs-index type of optimizing; I mean "transforming within the
relational calculus (algebra?) to a
Yeb Havinga wrote:
> I'm now contemplating not using the 710 at all. Why should I not
> buy two 6Gbps SSDs without supercap (e.g. Intel 510 and OCZ Vertex
> 3 Max IOPS) with a IO controller+BBU?
Wouldn't the data be subject to loss between the time the IO
controller writes to the SSD and the t
Hello list,
A OCZ Vertex 2 PRO and Intel 710 SSD, both 100GB, in a software raid 1
setup. I was pretty convinced this was the perfect solution to run
PostgreSQL on SSDs without a IO controller with BBU. No worries for
strange firmware bugs because of two different drives, good write
endurance
Excelent !
You are right
Thanks a lot
Sabin
"Craig Ringer" wrote in message
news:4eb0a920.1010...@ringerc.id.au...
> On 11/01/2011 10:01 PM, Sabin Coanda wrote:
>> Hi there,
>>
>> I have the function:
>> CREATE OR REPLACE FUNCTION "Test"( ... )
>> RETURNS SETOF record AS
>> $BODY$
>> BEGIN
>>
Dear All
Thanks for your suggestions & replies.
The below are the sample query which i put for particular one bill_id
EXPLAIN ANALYZE SELECT abd.bill_no as
bill_no,to_char(abd.bill_date,'dd/mm/') AS date,mp.product_desc as
product_desc,std.quantity,std.area,rip.price AS rate
FROM acc_bill_it
29 matches
Mail list logo
