Re: [HACKERS] Hash Functions
От | Jeff Davis |
---|---|
Тема | Re: [HACKERS] Hash Functions |
Дата | |
Msg-id | CAMp0ubey3BApQ8oPp1GcJt-Q1OtAsXBdwLNtz3FVaQ5ohvAjgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Hash Functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Hash Functions
Re: [HACKERS] Hash Functions |
Список | pgsql-hackers |
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.
> 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
> 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
В списке pgsql-hackers по дате отправления: