Thread: Re: pgbench with partitioned tables

On Tue, Feb 11, 2025 at 3:10 AM Sergey Tatarintsev
<s.tatarintsev@postgrespro.ru> wrote:
>
> 08.02.2025 17:32, Álvaro Herrera пишет:
> > On 2025-Feb-07, Melanie Plageman wrote:
> >
> >> 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.
> > Sounds good.  I only wanted to say that I would use PQexecParams()
> > instead of PQexec() in the new function, avoiding the psprintf and
> > pfree, and also that initializing relkind to RELKIND_RELATION is strange
> > and probably unnecessary.
> >
> Let it be so. I made the suggested changes (patch v4 attached)

I was testing with this with the intent to commit it and noticed that
it does change behavior in one way -- previously if you created an
unlogged table with the same schema as one of the pgbench tables and
then used client-side data generation, it would COPY FREEZE data into
that table. With the patch, it would no longer do that. I can live
with that, but I thought it was worth mentioning.

- Melanie

On Tue, Feb 11, 2025 at 2:29 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> On Tue, Feb 11, 2025 at 3:10 AM Sergey Tatarintsev
> <s.tatarintsev@postgrespro.ru> wrote:
> >
> > 08.02.2025 17:32, Álvaro Herrera пишет:
> > > On 2025-Feb-07, Melanie Plageman wrote:
> > >
> > >> 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.
> > > Sounds good.  I only wanted to say that I would use PQexecParams()
> > > instead of PQexec() in the new function, avoiding the psprintf and
> > > pfree, and also that initializing relkind to RELKIND_RELATION is strange
> > > and probably unnecessary.
> > >
> > Let it be so. I made the suggested changes (patch v4 attached)
>
> I was testing with this with the intent to commit it and noticed that
> it does change behavior in one way -- previously if you created an
> unlogged table with the same schema as one of the pgbench tables and
> then used client-side data generation, it would COPY FREEZE data into
> that table. With the patch, it would no longer do that. I can live
> with that, but I thought it was worth mentioning.

I am also wondering whether or not adding a pgbench test is
appropriate. I don't see any other pgbench tests which test data
generation when DDL was done by the user. I'm thinking maybe this is
kind of a supported but undocumented use case. In which case maybe we
don't want a test for it?

- Melanie

On Tue, Feb 11, 2025 at 2:29 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> I was testing with this with the intent to commit it and noticed that
> it does change behavior in one way -- previously if you created an
> unlogged table with the same schema as one of the pgbench tables and
> then used client-side data generation, it would COPY FREEZE data into
> that table. With the patch, it would no longer do that. I can live
> with that, but I thought it was worth mentioning.

whoops, ignore this! I got turned around in the
RELKIND_/RELPERSISTANCE_ macro section of pg_class.h.

Anyway, I've committed this patch. I updated the docs but didn't add a
test this time. I'm still not sure how much we want to codify our
support of pgbench loading data into different kinds of user-defined
tables.

- Melanie