Re: How to reduce latency with fast short queries in Postgresql 15.3 on a NUMA server

Thanks for your reply, Ken.

With such a big server I was convinced that we should see a boost
everywhere, but after spending so much time tweaking and looking at so many
parameters on Linux, Postgresql and our current setup, I started to think
that maybe that latency was intrinsic to the hardware and therefore
inevitable. So after all, the CPU clock speed still counts these days! I
think we're many just looking at the number of CPU cores and forgetting
that the clock speed is still relevant for many tasks.

I guess those simple short queries are very sensible to the hardware specs
and there is no room for improving as much as the heavy queries in recent
versions of Postgres, as I have seen in my tests.

On Wed, 31 May 2023 at 15:47, Kenneth Marshall <ktm(at)rice(dot)edu> wrote:

> On Wed, May 31, 2023 at 02:40:05PM +0200, Sergio Rus wrote:
> > Hi guys,
> >
> > I've been configuring a new server and tuning Postgresql 15.3, but I'm
> > struggling with a latency I'm consistently seeing with this new server
> when
> > running fast short queries, compared to the other server.
> >
> > We're running two different versions of Postgresql:
> >
> > - Server A: Postgresql 9.3
> > - Server B: Postgresql 15.3
> >
> > Server B is the new server and is way more powerful than server A:
> >
> > - Server A: 1x Intel Xeon E3-1270 3.5GHz, 2x 8GB DDR3, RAID0
> > - Server B: 2x Intel Xeon Platinum 8260 2.4GHz, 4x 16GB DDR4, RAID1
> > ...
> > Conclusion:
> >
> > As you can see, server B has 2 CPUs and is using NUMA on Linux. And the
> > CPU clock is slower on server B than server A. Maybe any of those are
> > causing that latency?
> >
>
> Hi Sergio,
>
> This really looks like it is caused by the CPU clock speed difference.
> The E3 is 1.6X faster at the base frequency. Many times that is the
> trade-off when going to many more cores. Simple short will run faster on
> the older CPU even though overall the new CPU has much more total
> capacity.
>
> Regards,
> Ken
>