Re: Large expressions in indexes can't be stored (non-TOASTable)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Large expressions in indexes can't be stored (non-TOASTable)
Date: 2024-10-16 01:24:32
Message-ID: Zw8V0ClvZbUi2QQl@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 15, 2024 at 08:20:17PM -0500, Nathan Bossart wrote:
> On Wed, Oct 16, 2024 at 09:12:31AM +0900, Michael Paquier wrote:
> > - if (!ctx->rel->rd_rel->reltoastrelid)
> > + if (!OidIsValid(RelationGetToastRelid(ctx->rel)))
> >
> > This set of diffs in 0002 is a nice cleanup. I'd wish for relying
> > less on zero comparitons when assuming that InvalidOid is in use.
>
> I'm wondering if there's any concern about this one causing back-patching
> pain. If so, I can just add the macro for use in new code.

This bit does not concern me much. manipulations of reltoastrelid
from Relations are not that common in bug fixes.

> I assume all of this will get compiled out in non-USE_ASSERT_CHECKING
> builds as-is, but I see no problem with surrounding it with an #ifdef to be
> sure.

Yeah, I'm not sure that that would always be the case when optimized.
Code generated can be dumb sometimes even if compilers got much
smarter in the last 10 years or so (not compiler guy here).
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-10-16 01:26:06 Re: Doc: shared_memory_size_in_huge_pages with the "SHOW" command.
Previous Message Alena Rybakina 2024-10-16 01:22:29 Re: Fixing Hash Join bug I caused with adf97c156