On 2017/05/17 5:25, Jeff Davis wrote:
> On Tuesday, May 16, 2017, Robert Haas <robertmhaas@gmail.com> wrote:
>> I don't really find this a very practical design. If the table
>> partitions are spread across different relfilenodes, then those
>> relfilenodes have to have separate pg_class entries and separate
>> indexes, and those indexes also need to have separate pg_class
>> entries. Otherwise, nothing works. And if they do have separate
>> pg_class entries, then the partitions have to have their own names,
>> and likewise for their indexes, and a dump-and-reload has to preserve
>> those names. If it doesn't, and those objects get new system-assigned
>> names after the dump-and-reload, then dump restoration can fail when a
>> system-assigned name collides with an existing name that is first
>> mentioned later in the dump.
>
> Why can't hash partitions be stored in tables the same way as we do TOAST?
> That should take care of the naming problem.
There is only one TOAST table per relation though, containing all of the
relation's TOASTed data. Doesn't the multiplicity of hash partitions pose
a problem? Will a hash partition of given name end up with the same
subset of data in the target database as it did in the source database? I
suppose it won't matter though if we make hash partitions an
implementation detail of hash partitioned tables to the extent you
described in your earlier email [1], whereby it doesn't matter to an
application which partition contains what subset of the table's data.
Thanks,
Amit
[1]
https://www.postgresql.org/message-id/CAMp0ubcQ3VYdU1kNUCOmpj225U4hk6ZEoaUVeReP8h60p%2Bmv1Q%40mail.gmail.com