Kumar, Virendra wrote:
> Can somebody help me avoid nested loops in below query:
> --
> ap_poc_db=# explain (analyze,buffers)
> ap_poc_db-# select site_id, account_id FROM ap.site_exposure se
> ap_poc_db-# WHERE se.portfolio_id=-1191836
> ap_poc_db-# AND EXISTS (select 1 from ap
Hi,
I've tried to run a benchmark, similar to this one:
https://www.postgresql.org/message-id/flat/CAHyXU0yiVvfQAnR9cyH%3DHWh1WbLRsioe%3DmzRJTHwtr%3D2azsTdQ%40mail.gmail.com#CAHyXU0yiVvfQAnR9cyH=HWh1WbLRsioe=mzRJTHwtr=2azs...@mail.gmail.com
CREATE TABLESPACE test OWNER postgres LOCATION '/path/
We moved our stuff out of AWS a little over a year ago because the
performance was crazy inconsistent and unpredictable. I think they do a
lot of oversubscribing so you get strange sawtooth performance patterns
depending on who else is sharing your infrastructure and what they are
doing at the tim
I've tried to re-run the test for some specific values of
effective_io_concurrency. The results were the same.
That's why I don't think the order of tests or variability in "hardware"
performance affected the results.
Regards,
Vitaliy
On 31/01/2018 15:01, Rick Otten wrote:
We moved our stuff
2018-01-31 14:15 GMT+01:00 Vitaliy Garnashevich :
> I've tried to re-run the test for some specific values of
> effective_io_concurrency. The results were the same.
>
> That's why I don't think the order of tests or variability in "hardware"
> performance affected the results.
>
AWS uses some int
> I've tried to re-run the test for some specific values of
> effective_io_concurrency. The results were the same.
> That's why I don't think the order of tests or variability in "hardware"
> performance affected the results.
We run many MS SQL server VMs in AWS with more than adequ
More tests:
io1, 100 GB:
effective_io_concurrency=0
Execution time: 40333.626 ms
effective_io_concurrency=1
Execution time: 163840.500 ms
effective_io_concurrency=2
Execution time: 162606.330 ms
effective_io_concurrency=4
Execution time: 163670.405 ms
effective_io_concurrency=8
Execution ti
On Wed, Jan 31, 2018 at 1:57 PM, Vitaliy Garnashevich
wrote:
> More tests:
>
> io1, 100 GB:
>
> effective_io_concurrency=0
> Execution time: 40333.626 ms
> effective_io_concurrency=1
> Execution time: 163840.500 ms
In my experience playing with prefetch, e_i_c>0 interferes with kernel
read-ahea
I've done some more tests. Here they are all:
io1, 100 GB SSD, 1000 IOPS
effective_io_concurrency=0 Execution time: 40333.626 ms
effective_io_concurrency=1 Execution time: 163840.500 ms
effective_io_concurrency=2 Execution time: 162606.330 ms
effective_io_concurrency=4 Execution time: 163670.405
On Wed, Jan 31, 2018 at 4:03 AM, Vitaliy Garnashevich <
vgarnashev...@gmail.com> wrote:
>
> The results look really confusing to me in two ways. The first one is that
> I've seen recommendations to set effective_io_concurrency=256 (or more) on
> EBS.
I would not expect this to make much of a dif
HI I think this parameter will be usefull when the storage using RAID stripe , otherwise turn up this parameter is meaningless when only has one device。
发自网易邮箱大师
On 2/1/2018 04:29，Vitaliy Garnashevich wrote：
Hi all,
Regarding this archive log generation found one observation.
A table named abc_table id found to be archived every 9'th and 39'th minute.
We are able to find number of tuples deleted from the pg_stat_user_tables
view.
But to my wonder the number of tuple inserts are shown 0. How can
12 matches
Mail list logo
