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.
> * Reuse the result from the p
Matthias,
Rebased patch attached.
Changes in v14:
* UpdateContext now the location I've stored estate, resultRelInfo, etc.
* Reuse the result from the predicate on the partial index.
-greg
> On Mar 7, 2025, at 5:47 PM, Matthias van de Meent
> wrote:
>
> On Thu, 6 Mar 2025 at 13:40, Burd,
> 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, 17 Feb 2025 at 20:54, Burd, Gr
On Thu, 6 Mar 2025 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 expressions and only once
> >
> > ExecExpressionIndexesUpdated seems to
> 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 v1 of this patch is essentially gone in
>> v10.
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 v1 of this patch is essentially gone in
> v10. The overhead was due to re-creating IndexInfo information
> unnecessarily,
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.
On Mon, 17 Feb 2025 at 20:54, Burd, Greg wrote:
> On Feb 15, 2025, at 5:49 AM, Matthias van de Meent
> wrote:
> >
> > In HEAD, we have a clear i
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
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
Matthias,
First off, I can't thank you enough for taking the time to review in detail the
patch. I appreciate and value your time and excellent feedback.
Second, I think that I should admit to the fact that I've also been working on
making PHOT functional again. I have it rebased against mast
On Thu, 13 Feb 2025 at 19:46, Burd, Greg wrote:
>
> Attached find an updated patchset v5 that is an evolution of v4.
>
> Changes v4 to v5 are:
> * replaced GUC with table reloption called "expression_checks" (open to other
> name ideas)
> * minimal documentation updates to README.HOT to address c
Matthias,
Thanks for the in-depth review, you are correct and I appreciate you uncovering
that oversight with summarizing indexes. I’ll add a test case and modify the
logic to prevent updates to unchanged summarizing indexes by testing their
attributes against the modified set while keeping th
On Mon, 10 Feb 2025 at 19:15, Burd, Greg wrote:
>
> 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 unc
On Mon, 10 Feb 2025 at 20:11, Burd, Greg wrote:
> > 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 t
On Tue, 11 Feb 2025 at 00:20, Nathan Bossart wrote:
>
> On Mon, Feb 10, 2025 at 06:17:42PM +0100, Matthias van de Meent wrote:
> > I have serious doubts about the viability of any proposal working to
> > implement PHOT/WARM in PostgreSQL, as they seem to have an inherent
> > nature of fundamentall
On Mon, Feb 10, 2025 at 06:17:42PM +0100, Matthias van de Meent wrote:
> I have serious doubts about the viability of any proposal working to
> implement PHOT/WARM in PostgreSQL, as they seem to have an inherent
> nature of fundamentally breaking the TID lifecycle:
> We won't be able to clean up de
> 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
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
On Thu, 6 Feb 2025 at 23:24, Burd, Greg wrote:
>
> Attached find a patch that expands the cases where heap-only tuple (HOT)
> updates are possible without changing the basic semantics of HOT. This is
> accomplished by examining expression indexes for changes to determine if
> indexes require up
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
On Thu, 2025-02-06 at 22:24 +, Burd, Greg wrote:
> Attached find a patch that expands the cases where heap-only tuple (HOT)
> updates are possible
> without changing the basic semantics of HOT. This is accomplished by
> examining expression
> indexes for changes to determine if indexes requir
21 matches
Mail list logo
