On 6/13/22 17:42, Merlin Moncure wrote:
> On Sat, Jun 4, 2022 at 6:23 PM Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> wrote:
>
> Hi,
>
> At on of the pgcon unconference sessions a couple days ago, I presented
> a bunch of benchmark results comparing performance with differe
On Sat, Jun 4, 2022 at 6:23 PM Tomas Vondra
wrote:
> Hi,
>
> At on of the pgcon unconference sessions a couple days ago, I presented
> a bunch of benchmark results comparing performance with different
> data/WAL block size. Most of the OLTP results showed significant gains
> (up to 50%) with smal
> On 6/9/22 13:23, Jakub Wartak wrote:
> >>> The really
> >> puzzling thing is why is the filesystem so much slower for
> >> smaller pages. I mean, why would writing 1K be 1/3 of writing 4K?
> >> Why would a filesystem have such effect?
> >
> > Ha! I don't care at this point
On 6/9/22 13:23, Jakub Wartak wrote:
>>> The really
>> puzzling thing is why is the filesystem so much slower for smaller
>> pages. I mean, why would writing 1K be 1/3 of writing 4K?
>> Why would a filesystem have such effect?
>
> Ha! I don't care at this point as 1 or 2
> > The really
> puzzling thing is why is the filesystem so much slower for smaller
> pages. I mean, why would writing 1K be 1/3 of writing 4K?
> Why would a filesystem have such effect?
> >>>
> >>> Ha! I don't care at this point as 1 or 2kB seems too small to handle
> >>> many
On 6/8/22 16:15, Jakub Wartak wrote:
> Hi, got some answers!
>
> TL;DR for fio it would make sense to use many stressfiles (instead of 1) and
> same for numjobs ~ VCPU to avoid various pitfails.
> The really
puzzling thing is why is the filesystem so much slower for smaller
pages.
Hi, got some answers!
TL;DR for fio it would make sense to use many stressfiles (instead of 1) and
same for numjobs ~ VCPU to avoid various pitfails.
> >> The really
> >> puzzling thing is why is the filesystem so much slower for smaller
> >> pages. I mean, why would writing 1K be 1/3 of writing
On Tue, Jun 7, 2022 at 1:47 PM Tomas Vondra
wrote:
> Possibly, but why would that be the case? Maybe there are places that do
> stuff with memory and have different optimizations based on length? I'd
> bet the 4k page is way more optimized than the other cases.
I don't really know. It was just a
On 6/7/22 18:26, Robert Haas wrote:
> On Sat, Jun 4, 2022 at 7:23 PM Tomas Vondra
> wrote:
>> This opened a long discussion about possible explanations - I claimed
>> one of the main factors is the adoption of flash storage, due to pretty
>> fundamental differences between HDD and SSD systems. But
On Sat, Jun 4, 2022 at 7:23 PM Tomas Vondra
wrote:
> This opened a long discussion about possible explanations - I claimed
> one of the main factors is the adoption of flash storage, due to pretty
> fundamental differences between HDD and SSD systems. But the discussion
> concluded with an agreeme
On 6/7/22 15:48, Jakub Wartak wrote:
> Hi,
>
>> The really
>> puzzling thing is why is the filesystem so much slower for smaller pages. I
>> mean,
>> why would writing 1K be 1/3 of writing 4K?
>> Why would a filesystem have such effect?
>
> Ha! I don't care at this point as 1 or 2kB seems too
Hi,
> The really
> puzzling thing is why is the filesystem so much slower for smaller pages. I
> mean,
> why would writing 1K be 1/3 of writing 4K?
> Why would a filesystem have such effect?
Ha! I don't care at this point as 1 or 2kB seems too small to handle many real
world scenarios ;)
> > b
On 6/7/22 11:46, Jakub Wartak wrote:
> Hi Tomas,
>
>> Well, there's plenty of charts in the github repositories, including the
>> charts I
>> think you're asking for:
>
> Thanks.
>
>> I also wonder how is this related to filesystem page size - in all the
>> benchmarks I
>> did I used the defau
[..]
>I doubt we could ever
> make the default smaller than it is today as it would nobody would be able to
> insert rows larger than 4 kilobytes into a table anymore.
Add error "values larger than 1/3 of a buffer page cannot be indexed" to that
list...
-J.
Hi Tomas,
> Well, there's plenty of charts in the github repositories, including the
> charts I
> think you're asking for:
Thanks.
> I also wonder how is this related to filesystem page size - in all the
> benchmarks I
> did I used the default (4k), but maybe it'd behave if the filesystem page
On Sun, 5 Jun 2022 at 11:23, Tomas Vondra wrote:
> At on of the pgcon unconference sessions a couple days ago, I presented
> a bunch of benchmark results comparing performance with different
> data/WAL block size. Most of the OLTP results showed significant gains
> (up to 50%) with smaller (4k) da
Hello Tomas,
At on of the pgcon unconference sessions a couple days ago, I presented
a bunch of benchmark results comparing performance with different
data/WAL block size. Most of the OLTP results showed significant gains
(up to 50%) with smaller (4k) data pages.
You wrote something about SS
On 6/6/22 17:00, Tomas Vondra wrote:
>
> On 6/6/22 16:27, Jakub Wartak wrote:
>> Hi Tomas,
>>
>>> Hi,
>>>
>>> At on of the pgcon unconference sessions a couple days ago, I presented a
>>> bunch of benchmark results comparing performance with different data/WAL
>>> block size. Most of the OLTP r
On 6/6/22 16:27, Jakub Wartak wrote:
> Hi Tomas,
>
>> Hi,
>>
>> At on of the pgcon unconference sessions a couple days ago, I presented a
>> bunch of benchmark results comparing performance with different data/WAL
>> block size. Most of the OLTP results showed significant gains (up to 50%)
>> w
Hi Tomas,
> Hi,
>
> At on of the pgcon unconference sessions a couple days ago, I presented a
> bunch of benchmark results comparing performance with different data/WAL
> block size. Most of the OLTP results showed significant gains (up to 50%) with
> smaller (4k) data pages.
Nice. I just saw th
On 6/5/22 02:21, Roberto Mello wrote:
> On Sat, Jun 4, 2022 at 5:23 PM Tomas Vondra
> mailto:tomas.von...@enterprisedb.com>>
> wrote:
>
> Hi,
>
> At on of the pgcon unconference sessions a couple days ago, I presented
> a bunch of benchmark results comparing performance with differ
On Sat, Jun 4, 2022 at 5:23 PM Tomas Vondra
wrote:
> Hi,
>
> At on of the pgcon unconference sessions a couple days ago, I presented
> a bunch of benchmark results comparing performance with different
> data/WAL block size. Most of the OLTP results showed significant gains
> (up to 50%) with smal
22 matches
Mail list logo
