Re: no default hash partition

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: no default hash partition
Дата
Msg-id 20190806234208.GG29202@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: no default hash partition  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: no default hash partition  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >> Hmm.  So given the point about it being hard to predict which hash
> >> partitions would receive what values ... under what circumstances
> >> would it be sensible to not create a full set of partitions?  Should
> >> we just enforce that there is a full set, somehow?
>
> > I imagine there's good reasons this wasn't just done (for this or
> > various other things), but couldn't we enforce it by just creating them
> > all..?  Sure would simplify a lot of things for users.  Similairly for
> > list partitions, I would think.
>
> Well, with lists Alvaro's point holds: you might know a priori that
> some of the values are infrequent and don't deserve their own partition.
> The thing about hash is that the entries should (in theory) get spread
> out to all partitions pretty evenly, so it's hard to see why a user
> would want to treat any partition differently from any other.

Yeah, that's a fair argument, but giving the user a way to say that
would address it.  As in, "create me a list-partitioned table for these
values, plus a default."  Anyhow, I'm sure that I'm taking this beyond
what we need to do right now, just sharing where I think it'd be good
for things to go.

Thanks!

Stephen

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: no default hash partition
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: stress test for parallel workers