2018-07-17 11:43 GMT-03:00 Fabio Pardi :
>
>
> On 07/17/2018 04:05 PM, Neto pr wrote:
>> 2018-07-17 10:55 GMT-03:00 Fabio Pardi :
>
>>> Also i think it makes not much sense testing on RAID 0. I would start
>>> performing tests on a single disk, bypassing
2018-07-17 22:13 GMT-03:00 Neto pr :
> 2018-07-17 20:04 GMT-03:00 Mark Kirkwood :
>> Ok, so dropping the cache is good.
>>
>> How are you ensuring that you have one test setup on the HDDs and one on the
>> SSDs? i.e do you have 2 postgres instances? or are you
th a single SSD
>
> regards
> Mark
>
> On 18/07/18 01:04, Neto pr wrote (note snippage):
>
>> (echo 3> / proc / sys / vm / drop_caches;
>>
>> discs:
>> - 2 units of Samsung Evo SSD 500 GB (mounted on ZERO RAID)
>> - 2 SATA 7500 Krpm HDD units -
D ZERO.
> The findings should narrow the focus
>
>
> regards,
>
> fabio pardi
>
> On 07/17/2018 03:19 PM, Neto pr wrote:
>> 2018-07-17 10:04 GMT-03:00 Neto pr :
>>> Sorry.. I replied in the wrong message before ...
>>> follows my response.
>>
d on Debian 8 Operating System, how could I check the TRIM configuration ?
Best
[]'s Neto
>
> Nicolas
>
> Nicolas CHARLES
>
> Le 17/07/2018 à 15:19, Neto pr a écrit :
>>
>> 2018-07-17 10:04 GMT-03:00 Neto pr :
>>>
>>> Sorry.. I replied in the wro
2018-07-17 10:04 GMT-03:00 Neto pr :
> Sorry.. I replied in the wrong message before ...
> follows my response.
> -
>
> Thanks all, but I still have not figured it out.
> This is really strange because the tests were done on the same machine
> (I use HP ML110 Pr
es config?
> - what about vacuums or maintenance tasks running in the background?
>
> Also, to benchmark disks i would not use a custom query but pgbench.
>
> Be aware: running benchmarks is a science, therefore needs a scientific
> approach :)
>
> regards
>
> fabio
1TB (mounted on ZERO RAID)
- The Operating System and the Postgresql DBMS are installed on the SSD disk.
Best Regards
[ ]`s Neto
2018-01-16 13:24 GMT-08:00 Mark Kirkwood :
>
>
> On 16/01/18 23:14, Neto pr wrote:
>>
>> 2018-01-15 20:04 GMT-08:00 Mark Kirkwood :
>>>
>
Dear,
Some of you can help me understand this.
This query plan is executed in the query below (query 9 of TPC-H
Benchmark, with scale 40, database with approximately 40 gb).
The experiment consisted of running the query on a HDD (Raid zero).
Then the same query is executed on an SSD (Raid Zero).
llion)
240 million of the rows.
Regards
Neto
2018-05-05 8:16 GMT-07:00 Neto pr :
> Dear all
>
> Could you help me understand these two execution plans for the same
> query (query 3 benchmark TPCH www.tpc.org/tpch), executed in two
> different environments of Postgresql, as describe
Dear all
Could you help me understand these two execution plans for the same
query (query 3 benchmark TPCH www.tpc.org/tpch), executed in two
different environments of Postgresql, as described below. These plans
were generated by the EXPLAIN ANALYZE command, and the time of plan 1
was 4.7 minutes
Hi all,
I need to know the actual execution time of a query, but considering
that the data is already cached. I also need to make sure that cached
data from other queries is cleared.
I believe that in order to know the real time of a query it will be
necessary to "warm up" the data to be inserted i
2018-01-15 20:04 GMT-08:00 Mark Kirkwood :
> On 16/01/18 13:18, Fernando Hevia wrote:
>
>>
>>
>>
>> The 6 Gb/s interface is capable of a maximum throughput of around 600
>> Mb/s. None of your drives can achieve that so I don't think you are limited
>> to the interface speed. The 12 Gb/s interface s
2018-01-15 17:58 GMT-08:00 Justin Pryzby :
> On Mon, Jan 15, 2018 at 05:19:59PM -0800, Neto pr wrote:
>> >> Can you reproduce the speed difference using dd ?
>> >> time sudo dd if=/dev/sdX of=/dev/null bs=1M count=32K
>> >> skip=$((128*$RANDOM/32)) # set
2018-01-15 16:18 GMT-08:00 Fernando Hevia :
>
>
> 2018-01-15 20:25 GMT-03:00 Neto pr :
>>
>> 2018-01-15 17:55 GMT-02:00 Fernando Hevia :
>> >
>> >
>> > 2018-01-15 15:32 GMT-03:00 Georg H. :
>> >>
>> >>
>> >> H
2018-01-15 17:55 GMT-02:00 Fernando Hevia :
>
>
> 2018-01-15 15:32 GMT-03:00 Georg H. :
>>
>>
>> Hello Neto
>>
>> Am 14.01.2018 um 21:44 schrieb Neto pr:
>>>
>>> Dear all
>>>
>>> Someone help me analyze the two execution pl
transfer rate of 6Gb/s equal to the SSD SATA 6Gb/s, do you think the
SSD would be more agile in this case?
HDD: HP 450GB 6G SAS 15K rpm LFF (3.5-inch) Part-Number: 652615-B21
best Regards
Neto
2018-01-15 16:32 GMT-02:00 Georg H. :
>
> Hello Neto
>
> Am 14.01.2018 um 21:44 schrieb Neto pr:
&g
2018-01-15 3:04 GMT-08:00 Neto pr :
> 2018-01-14 19:09 GMT-08:00 Justin Pryzby :
>> On Sun, Jan 14, 2018 at 06:25:40PM -0800, Neto pr wrote:
>>> > The query plan is all garbled by mail , could you resend? Or post a
link from
>>> > https://explain.depesz.com/
&g
2018-01-14 19:09 GMT-08:00 Justin Pryzby :
> On Sun, Jan 14, 2018 at 06:25:40PM -0800, Neto pr wrote:
>> > The query plan is all garbled by mail , could you resend? Or post a link
>> > from
>> > https://explain.depesz.com/
>
> On Sun, Jan 14, 2018 at 06:36:02P
2018-01-14 15:59 GMT-08:00 Neto pr :
> Thanks for the reply.
> I'll try upload the execution plan with Explain (analyse, buffer) for
> website: https://explain.depesz.com/
>
Below is a new execution plan, with Analyze, BUFFERS. This time,
without changing anything in the con
2018-01-14 13:40 GMT-08:00 Justin Pryzby :
> On Sun, Jan 14, 2018 at 12:44:00PM -0800, Neto pr wrote:
>> Dear all
>>
>> Someone help me analyze the two execution plans below (Explain ANALYZE
>> used), is the query 9 of TPC-H benchmark [1].
>>
>> I'
email&utm_source=link&utm_campaign=sig-email&utm_content=webmail";
target="_blank" style="color: #4453ea;">www.avast.com.
2018-01-14 19:40 GMT-02:00 Justin Pryzby :
> On Sun, Jan 14, 2018 at 12:44:00PM -0800, Neto pr wrote:
>&
Dear all
Someone help me analyze the two execution plans below (Explain ANALYZE
used), is the query 9 of TPC-H benchmark [1].
I'm using a server HP Intel Xeon 2.8GHz/4-core - Memory 8GB HDD SAS 320GB
15 Krpm AND SSD Sansung EVO 500GB.
My DBMS parameters presents in postgresql.conf is default, but
23 matches
Mail list logo
