| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Remove fcinfo from statistics update internal functions |
| Date: | 2026-09-04 01:35:25 |
| Message-ID: | apogXK47NGJY8fWw@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Sep 03, 2026 at 01:42:09PM -0500, Nathan Bossart wrote:
> On Thu, Sep 03, 2026 at 12:35:26PM +0900, Michael Paquier wrote:
>> Hmm. Adding Nathan in CC on this one for comment from the RMT. It's
>> rather low priority compared to all the open items I can see listed on
>> the wiki, but it's an option I find worth considering by the day. I
>> don't want to put more stress than necessary on the RMT regarding this
>> thread, though..
>
> From later the discussion, it looks like there's nothing that needs RMT
> review at the moment. Please let me know if I've got that wrong.
FWIW, the best conclusion that I can offer regarding this thread on my
side is that I am pretty unhappy with the decisions taken on
REL_19_STABLE on the core backend side regarding the way the stats
import code has been plugged, reflecting in the way FDWs need to work
with that. It is not entirely the fault of the stats import code,
because the stats import code has been trying to work around decisions
that have been taken in v18 for the relation and attribute stats.
What feels wrong to me is that we are trying to work around these
decisions after-the-fact. A more logical flow that I try to follow is
first to fix the original underlying issues, even if it means
reverting any new code, provide a clean basis, then work on top of the
clean basis, and not work *around* them.
That pretty much reflects my feeling regarding this thread: 0001 is a
reflection of what looks like a workaround (the "unused" bits are one
part of that, but not everything I feel rather weird about), and the
early choices from v18 reflect into the rest in the code tree in what
spreads as unelegant ways. That has a long-term cost I'd like to not
underestimate.
Using structures and splitting the dependencies between the stats
restore and stats import logic as I was proposing was providing a
cleaner split, IMO. Even if I agree that it still is a sort of
workaround, there is nothing better I can propose as long as we don't
have a cleaner basis. I don't think that I would not have done things
this way and did not originally commit any of that, so I'm by
definition not its owner and we all have our style quirks. In terms
of my own qwirks I tend to pick up community-style consistency, not of
all us do which is fine by me. So, shrug? ¯\(ツ)/¯
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Paul Kim | 2026-09-04 01:29:18 | Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish |