From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-committers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] [COMMITTERS] pgsql: Improve performance of SendRowDescriptionMessage. |
Date: | 2022-08-13 19:08:43 |
Message-ID: | 20220813190843.wrs3feelaxy434un@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Hi Noah,
On 2017-10-13 11:24:05 -0700, Andres Freund wrote:
> On 2017-10-13 14:19:22 -0400, Tom Lane wrote:
> > > So it'd probably better to introduce a FORCE_DISABLE_RESTRICT=yes, set
> > > at the same place, that's then tested before running the relevant
> > > configure check?
> >
> > +1. I think you don't actually have to skip the configure check,
> > and there might be some value in letting it carry on normally
> > (so that "restrict" is set properly). We'd just want it to affect
> > what pg_restrict gets defined as. Something like
>
> > if test "$ac_cv_c_restrict" = "no" -o "x$FORCE_DISABLE_RESTRICT" = "xyes"; then
> > pg_restrict=""
> > else
> > pg_restrict="$ac_cv_c_restrict"
>
> Yea, that works. Will make it so.
Any chance you could check if this is still needed? I've a FIXME about it in
the meson code that I'd like to get rid of :)
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-08-13 19:21:50 | pgsql: Catch stack overflow when recursing in transformFromClauseItem() |
Previous Message | Tom Lane | 2022-08-13 17:37:15 | pgsql: Remove configurability of PPC spinlock assembly code. |
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-08-13 19:17:46 | Re: [patch]HashJoin crash |
Previous Message | Tom Lane | 2022-08-13 18:07:40 | Re: Cleaning up historical portability baggage |