Re: pgbench with partitioned tables

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Sergey Tatarintsev <s(dot)tatarintsev(at)postgrespro(dot)ru>
Cc: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "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-07 23:15:58
Message-ID: CAAKRu_bq3z7oQ4SQRh1EOMFque1xDDO_UdDub+d0XiE4rpGrtw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 3, 2025 at 7:23 AM Sergey Tatarintsev
<s(dot)tatarintsev(at)postgrespro(dot)ru> wrote:
>
> 03.02.2025 14:57, Álvaro Herrera пишет:
> > On 2025-Feb-03, Sergey Tatarintsev wrote:
> >
> >> Thanks for the note. I changed the query in the patch (v2 patch attached)
> >>
> >> Btw, an additional benefit from the patch is that we can use foreign tables
> >> (for example, to test postgres_fdw optimizations)
> > Good thought, and maybe it would be better if the new function was
> > "get_table_relkind" which just returns the char, and this check
> >
> >> + /* Use COPY with FREEZE on v14 and later for all regular tables */
> >> + if ((PQserverVersion(con) >= 140000) && is_regular_table(con, table))
> >> copy_statement_fmt = "copy %s from stdin with (freeze on)";
> > can be "&& get_table_relkind(con, table) == RELKIND_RELATION"
> >
> > which I think is more natural.
> >
> sounds reasonable.
>
> patch v3 attached

Okay, I've stared at this a bit, and it seems basically fine the way
it is (I might add a bit more whitespace, clean up the commit message,
etc). So I'm interested in committing it. I will admit that having
never committed anything to pgbench, I'm a bit nervous. So, give me a
couple days to work up the nerve.

- Melanie

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2025-02-07 23:26:44 Re: Fix for Extra Parenthesis in pgbench progress message
Previous Message James Hunter 2025-02-07 22:43:12 Re: should we have a fast-path planning for OLTP starjoins?