| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Predefined role pg_maintenance for VACUUM, ANALYZE, CHECKPOINT. |
| Date: | 2021-10-26 21:03:24 |
| Message-ID: | 423ff64d88c6817551ea81e0b554202992184bac.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2021-10-26 at 16:02 -0400, Stephen Frost wrote:
> We're talking about benchmarking tools
What I had in mind was something much less formal, like a self-
contained repro case of a performance problem.
... simple schema
... data load
... maybe build some indexes
... maybe set hints
VACUUM ANALYZE;
CHECKPOINT;
I'm not saying it's a very strong use case, but at least for me, it's
kind of a habit to throw in a CHECKPOINT after a quick data load for a
test, even if it might not matter for whatever I'm testing.
I guess I can change my habit to use a function instead, but then
what's the point of the syntax?
Should we just add a builtin function pg_checkpoint(), and deprecate
the syntax?
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2021-10-26 21:04:14 | Re: Allow pg_signal_backend members to use pg_log_backend_memory_stats(). |
| Previous Message | Robert Haas | 2021-10-26 21:02:18 | Re: Next Steps with Hash Indexes |