| From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: relfilenode statistics |
| Date: | 2025-03-13 09:00:52 |
| Message-ID: | CALdSSPh76=ACN=z68oM44ZMgZsQxTTYVF8qvi1F6TGA5Mn6uiQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 3 Jan 2025 at 21:18, Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> As mentioned by Andres in [1], relying on the relation OID would not work to
> "recover" the stats because we don't have access to the relation oid during crash
> recovery. So, I'm going to resume working on the "initial" idea (i.e having the
> stats keyed by relfilenode).
>
> [1]: https://www.postgresql.org/message-id/xvetwjsnkhx2gp6np225g2h64f4mfmg6oopkuaiivrpzd2futj%40pflk55su36ho
>
Hmm. While it is true that catalog lookups cannot be performed during
crash recovery, is it really necessary to save and retrieve statistics
after a crash? Given that statistics are permitted to be outdated and
server crashes are anticipated to be infrequent, it looks loke losing
a few analysis runs due to server crashes is acceptable.
In any case, I am totally OK with the relfilenode-based method because
it is generally less restricted (to other postgresql parts e.g. wal-
replay ) and simpler.
Also, this patch needs a rebase;)
--
Best regards,
Kirill Reshke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2025-03-13 09:04:15 | Random pg_upgrade 004_subscription test failure on drongo |
| Previous Message | Amit Kapila | 2025-03-13 08:43:39 | Re: Selectively invalidate caches in pgoutput module |