|From:||Stephen Frost <sfrost(at)snowman(dot)net>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: no default hash partition|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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.
|Next Message||Thomas Munro||2019-08-06 23:57:23||Re: stress test for parallel workers|
|Previous Message||Tom Lane||2019-08-06 23:35:12||Re: no default hash partition|