On Tuesday, May 16, 2017, Robert Haas <robertmh...@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. > If Java has portable hash functions, why can't we? Java standardizes on a particular unicode encoding (utf-16). Are you suggesting that we do the same? Or is there another solution that I am missing? Regards, Jeff Davis
