Re: Enable data checksums by default

> On Jul 31, 2025, at 6:10 PM, Jeff Davis wrote: > > On Thu, 2025-07-31 at 17:21 +0200, Tomas Vondra wrote: >> On 7/31/25 15:39, Greg Burd wrote: >>> I recall a conversation at the last PGConf.dev (2025) with a >>> representative >>> from Intel and Jeff Davis (CC’ed) that had to do with checks

Re: Enable data checksums by default

> On Jul 31, 2025, at 3:21 PM, Laurenz Albe wrote: > > On Thu, 2025-07-31 at 09:39 -0400, Greg Burd wrote: >> I agree that enabling checksums by default is the sane default. Databases >> should always make a best effort for data integrity, checksums are a >> positive step in that direction. >

Re: Changing shared_buffers without restart

> On Jul 14, 2025, at 10:01 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: > >> On Mon, Jul 14, 2025 at 09:42:46AM -0400, Andres Freund wrote: >> What on earth would be the point of putting a buffer on the freelist but not >> make it reachable by the clock sweep? To me that's just nonsensical.

Re: Adding basic NUMA awareness

> On Jul 10, 2025, at 8:13 AM, Burd, Greg wrote: > > >> On Jul 9, 2025, at 1:23 PM, Andres Freund wrote: >> >> Hi, >> >> On 2025-07-09 12:55:51 -0400, Greg Burd wrote: >>> On Jul 9 2025, at 12:35 pm, Andres Freund wrote: >>> >&

Re: Adding basic NUMA awareness

> On Jul 9, 2025, at 1:23 PM, Andres Freund wrote: > > Hi, > > On 2025-07-09 12:55:51 -0400, Greg Burd wrote: >> On Jul 9 2025, at 12:35 pm, Andres Freund wrote: >> >>> FWIW, I've started to wonder if we shouldn't just get rid of the freelist >>> entirely. While clocksweep is perhaps minute

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

> On Jul 7, 2025, at 7:38 PM, Michael Paquier wrote: > > I have also pushed this v2 on this branch, so feel free to grab it if > that makes your life easier: > https://github.com/michaelpq/postgres/tree/toast_64bit_v2 > -- > Michael Thank you for spending time digging into this and for the we

Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring

> On Jun 30, 2025, at 12:27 PM, Andres Freund wrote: > > Hi, > > On 2025-06-05 14:32:10 -0400, Andres Freund wrote: >> On 2025-06-05 12:47:52 -0400, Tom Lane wrote: >>> Andres Freund writes: I think this is a big enough pitfall that it's, obviously assuming the patch has a se

Re: Expanding HOT updates for expression and partial indexes

Apologies for the noise, I overlooked a compiler warning. fixed. -greg > On Mar 25, 2025, at 7:47 AM, Burd, Greg wrote: > > Matthias, > > Rebased patch attached. > > Changes in v14: > * UpdateContext now the location I've stored estate, resultRelInfo, etc.

Re: Expanding HOT updates for expression and partial indexes

25 at 13:40, Burd, Greg wrote: > >> >> >>> On Mar 5, 2025, at 6:39 PM, Matthias van de Meent >>> wrote: >>> >>> On Wed, 5 Mar 2025 at 18:21, Burd, Greg wrote: >>> >>>> * augments IndexInfo only when needed for testing

Re: Expanding HOT updates for expression and partial indexes

> On Mar 5, 2025, at 5:56 PM, Matthias van de Meent > wrote: > > Hi, > > Sorry for the delay. This is a reply for the mail thread up to 17 Feb, > so it might be very out-of-date by now, in which case sorry for the > noise. Never noise, always helpful. > On Mon,

Re: Expanding HOT updates for expression and partial indexes

> On Mar 5, 2025, at 6:39 PM, Matthias van de Meent > wrote: > > On Wed, 5 Mar 2025 at 18:21, Burd, Greg wrote: >> >> Hello, >> >> I've rebased and updated the patch a bit. The biggest change is that the >> performance penalty measured with

Re: Expanding HOT updates for expression and partial indexes

Hello, I've rebased and updated the patch a bit. The biggest change is that the performance penalty measured with v1 of this patch is essentially gone in v10. The overhead was due to re-creating IndexInfo information unnecessarily, which I found existed in the estate. I've added a few fields

Re: Expanding HOT updates for expression and partial indexes

Changes v6 to v7: * Fixed documentation oversight causing build failure * Changed how I convey attribute len/by-val in IndexInfo * Fixed method to shortcut index_unchanged_by_update() when possible -greg v7-0001-Expand-HOT-update-path-to-include-expression-and-.patch Description: v7-0001-Expa

Re: Expanding HOT updates for expression and partial indexes

. -greg > On Feb 15, 2025, at 5:49 AM, Matthias van de Meent > wrote: > > On Thu, 13 Feb 2025 at 19:46, Burd, Greg wrote: > > - > > I'm not a fan of how you replaced TU_UpdateIndexes with a bitmap. It > seems unergonomic and a waste of performance. >

Re: Expanding HOT updates for expression and partial indexes

the HOT optimization when only summarizing indexes are changed. thanks for finding this, -greg > On Feb 11, 2025, at 4:40 PM, Matthias van de Meent > wrote: > > On Mon, 10 Feb 2025 at 19:15, Burd, Greg wrote: >> >> Apologies for not being clear, this preserves

Re: Expanding HOT updates for expression and partial indexes

> On Feb 10, 2025, at 12:17 PM, Matthias van de Meent > wrote: > >> >> I have a few concerns with the patch, things I’d greatly appreciate your >> thoughts on: >> >> First, I pass an EState along the update path to enable running the checks >> in heapam, this works but leaves me feeling as

Re: Expanding HOT updates for expression and partial indexes

Apologies for not being clear, this preserves the current behavior for summarizing indexes allowing for HOT updates while also updating the index. No degradation here that I’m aware of, indeed the tests that ensure that behavior are unchanged and pass. -greg > On Feb 10, 2025, at 12:17 PM, Ma

Re: Expanding HOT updates for expression and partial indexes

On Feb 9, 2025, at 1:14 AM, Laurenz Albe wrote: > > I think that the goal of this patch is interesting and desirable. Thanks for taking a look at it. Which version did you prefer, v3 or v4? > The greatest concern for me is the performance impact. Agreed, I’m still looking for ways to minimize