Hello Amit,
One more comment: +typedef enum { PART_NONE, PART_RANGE, PART_HASH, PART_UNKNOWN } + partition_method_t; See, if we can eliminate PART_UNKNOWN.
I'm not very happy with this one, but I wanted to differentiate "we do know that it is not partitioned" from "we do not know if it is partitioned", and I did not have a better idea.
I don't see much use of same.
Although it is not used afterwards, we could display the partitioning information differently between the two cases. This is not done because I did not want to add more lines on the "normal" case.
It is used at one place where we can set PART_NONE without much loss. Having lesser invalid values makes code easier to follow.Looking more closely at this case: + else if (PQntuples(res) != 1) + { + /* unsure because multiple (or no) pgbench_accounts found */ + partition_method = PART_UNKNOWN; + partitions = 0; + } Is it ever possible to have multiple pgbench_accounts considering we have unique index on (relname, relnamespace) for pg_class?
The issue is that it is not directly obvious which relnamespace will be used by the queries which rely on non schema qualified "pgbench_accounts". Each schema could theoretically hold a pgbench_accounts table. As this is pretty unlikely, I did not attempt to add complexity to resolve taking into account the search_path, but just skipped to unknown in this case, which I expect nobody would hit in normal circumstances.
Another possible and unlikely issue is that pgbench_accounts could have been deleted but not pgbench_branches which is used earlier to get the current "scale". If so, the queries will fail later on anyway.
-- Fabien.
