Re: pgbench - allow to create partitioned tables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Asif Rehman <asifr(dot)rehman(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench - allow to create partitioned tables
Date: 2019-09-13 17:35:57
Message-ID: alpine.DEB.2.21.1909131604190.10531@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Amit,

>>> + res = PQexec(con,
>>> + "select p.partstrat, count(*) "
>>> + "from pg_catalog.pg_class as c "
>>> + "left join pg_catalog.pg_partitioned_table as p on (p.partrelid = c.oid) "
>>> + "left join pg_catalog.pg_inherits as i on (c.oid = i.inhparent) "
>>> + "where c.relname = 'pgbench_accounts' "
>>> + "group by 1, c.oid");
>>>
>>> Can't we write this query with inner join instead of left join? What
>>> additional purpose you are trying to serve by using left join?
>>
>> I'm ensuring that there is always a one line answer, whether it is
>> partitioned or not. Maybe the count(*) should be count(something in p) to
>> get 0 instead of 1 on non partitioned tables, though, but this is hidden
>> in the display anyway.
>
> Sure, but I feel the code will be simplified. I see no reason for
> using left join here.

Without a left join, the query result is empty if there are no partitions,
whereas there is one line with it. This fact simplifies managing the query
result afterwards because we are always expecting 1 row in the "normal"
case, whether partitioned or not.

>>> +partition_method_t partition_method = PART_NONE;
>>>
>>> It is better to make this static.
>>
>> I do agree, but this would depart from all other global variables around
>> which are currently not static.
>
> Check QueryMode.

Indeed, there is a mix of static (about 8) and non static (29 cases). I
think static is better anyway, so why not.

Attached a v7.

--
Fabien.

Attachment Content-Type Size
pgbench-init-partitioned-7.patch text/x-diff 12.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-09-13 17:39:38 Re: psql - improve test coverage from 41% to 88%
Previous Message Alexander Korotkov 2019-09-13 17:17:23 Re: Bug in GiST paring heap comparator