From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, David Fetter <david(at)fetter(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Greg Stark <stark(at)mit(dot)edu>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, amul sul <sulamul(at)gmail(dot)com> |
Subject: | Re: Hash Functions |
Date: | 2017-05-17 18:35:17 |
Message-ID: | 1044.1495046117@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, May 16, 2017 at 4:25 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>> Why can't hash partitions be stored in tables the same way as we do TOAST?
>> That should take care of the naming problem.
> Hmm, yeah, something like that could be done, but every place where
> you are currently allowed to refer to a partition by name would have
> to be be changed to accept some other syntax for specifying the
> partition.
Uh ... toast tables have regular names, and can be specified in commands
just like any other table. I don't see why these "auto" partition tables
couldn't be handled the same way.
> Beyond that, I think it's a bad idea to make hash partitions behave
> completely differently from list and range partitions.
I think the question is whether we are going to make a distinction between
logical partitions (where the data division rule makes some sense to the
user) and physical partitions (where it needn't). I think it might be
perfectly reasonable for those to behave differently.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-05-17 18:37:14 | Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.) |
Previous Message | Tom Lane | 2017-05-17 18:31:12 | pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.) |