From: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Sergey Tatarintsev <s(dot)tatarintsev(at)postgrespro(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgbench with partitioned tables |
Date: | 2025-02-02 13:45:35 |
Message-ID: | 202502021345.roijlwskkwu6@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2025-Jan-31, Melanie Plageman wrote:
> Maybe instead of just not using COPY FREEZE on a table if it is
> partitioned, we could add new data generation init_steps. Perhaps one
> that is client-side data generation (g) but with no freezing? I'm not
> really sure what the letter would be (f? making it f, g, and G?).
I think it makes sense to do what you suggest, but on the other hand,
the original code that Sergey is patching looks like a hack in the sense
that it hardcodes which tables to use FREEZE with. There's no point to
doing things that way actually, so accepting Sergey's patch to replace
that with a relkind check feels sensible to me.
I think the query should be
SELECT relkind FROM pg_catalog.pg_class WHERE oid='%s'::pg_catalog.regclass
if only for consistency with pgbench's other query on catalogs.
Your proposal to add different init_steps might be reasonable, at least
if we allowed partitionedness of tables to vary in other ways (eg. if we
made pgbench_history partitioned), but I don't think it conflicts with
Sergey's patch in spirit.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Here's a general engineering tip: if the non-fun part is too complex for you
to figure out, that might indicate the fun part is too ambitious." (John Naylor)
https://postgr.es/m/CAFBsxsG4OWHBbSDM%3DsSeXrQGOtkPiOEOuME4yD7Ce41NtaAD9g%40mail.gmail.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Friedman | 2025-02-02 15:10:54 | Doc fix of aggressive vacuum threshold for multixact members storage |
Previous Message | Álvaro Herrera | 2025-02-02 13:24:29 | Re: Proposal to CREATE FOREIGN TABLE LIKE |