Hi,
On 2018/11/13 22:59, Alvaro Herrera wrote:
> On 2018-Nov-13, Michael Paquier wrote:
>
>> On Tue, Nov 13, 2018 at 09:58:08AM -0300, Alvaro Herrera wrote:
>>> "the context that was active when the function was called" is typically
>>> expressed simply as "the current memory context". Perhaps t
On Tue, Nov 13, 2018 at 10:59:15AM -0300, Alvaro Herrera wrote:
> I gave the patch a read and it looks reasonable to me.
>
> Memory management in RelationBuildPartitionDesc is crummy, but I don't
> think it's this patch's fault.
I agree, and that shows up pretty clearly after the refactoring is d
On 2018-Nov-13, Michael Paquier wrote:
> On Tue, Nov 13, 2018 at 09:58:08AM -0300, Alvaro Herrera wrote:
> > "the context that was active when the function was called" is typically
> > expressed simply as "the current memory context". Perhaps the whole
> > phrase can be reduced to "The object ret
On Tue, Nov 13, 2018 at 09:58:08AM -0300, Alvaro Herrera wrote:
> "the context that was active when the function was called" is typically
> expressed simply as "the current memory context". Perhaps the whole
> phrase can be reduced to "The object returned by this function is wholly
> allocated in
"the context that was active when the function was called" is typically
expressed simply as "the current memory context". Perhaps the whole
phrase can be reduced to "The object returned by this function is wholly
allocated in the current memory context"?
--
Álvaro Herrerahttps://
On 2018/11/13 12:40, Amit Langote wrote:
> On 2018/11/13 11:34, Michael Paquier wrote:
>> Attached is an updated patch. Perhaps you are spotting something else?
>
> Looks good to me.
Marked the CF entry as Ready for Committer.
Thanks,
Amit
On 2018/11/13 11:34, Michael Paquier wrote:
> Attached is an updated patch. Perhaps you are spotting something else?
Looks good to me.
Thanks,
Amit
On Tue, Nov 13, 2018 at 10:34:50AM +0900, Amit Langote wrote:
> Hmm, Assert or elog is your call, but I'd learned that we prefer elog when
> checking a value read from the disk?
Let's keep elog() then, which is consistent with the previous code. If
there is any meaning in switching to an assert()
Hi,
On 2018/11/12 22:55, Michael Paquier wrote:
> On Thu, Nov 08, 2018 at 03:11:35PM +0900, Amit Langote wrote:
>> And here is the new version. The break down into smaller local
>> functions for different partitioning methods is in patch 0002.
>
> Okay, here we go.
Thank you for reviewing.
> I
On Thu, Nov 08, 2018 at 03:11:35PM +0900, Amit Langote wrote:
> And here is the new version. The break down into smaller local
> functions for different partitioning methods is in patch 0002.
Okay, here we go. I have spent a couple of hours on this patch,
checking the consistency of the new code
On 2018-Nov-08, Amit Langote wrote:
> On 2018/11/08 0:04, Alvaro Herrera wrote:
> >> On Wed, Nov 07, 2018 at 03:34:38PM +0900, Amit Langote wrote:
> >>> I think we can design the interface of partition_bounds_create such that
> >>> it returns information needed to re-arrange OIDs to be in the cano
On 2018/11/08 12:59, Amit Langote wrote:
> It might be okay to split the big switch in partition_bounds_create() into
> different functions for different partitioning methods for clarity as you
> say, but let's avoid creating new files for range, list, and hash.
>
> I will post an updated patch wi
On 2018/11/08 0:04, Alvaro Herrera wrote:
>> On Wed, Nov 07, 2018 at 03:34:38PM +0900, Amit Langote wrote:
>>> I think we can design the interface of partition_bounds_create such that
>>> it returns information needed to re-arrange OIDs to be in the canonical
>>> partition bound order, so the actua
On 2018/11/08 11:48, Michael Paquier wrote:
>>> Thinking crazy, we could also create a subfolder partitioning/bounds/
>>> which includes three files with this refactoring:x
>>> - range.c
>>> - values.c
>>> - hash.c
>>> Then we keep partbounds.c which is the entry point used by partcache.c,
>>> and
On Wed, Nov 07, 2018 at 12:04:27PM -0300, Alvaro Herrera wrote:
> On 2018-Nov-07, Michael Paquier wrote:
> This is interesting. I don't think the current interface is so bad that
> we can't make a few tweaks later; IOW let's focus on the current patch
> for now, and we can improve later. You (and
On 2018-Nov-07, Michael Paquier wrote:
> On Wed, Nov 07, 2018 at 03:34:38PM +0900, Amit Langote wrote:
> > On 2018/11/05 16:21, Michael Paquier wrote:
> >> On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote:
> >>> Done a few moments ago. :)
> >>
> >> From the file size this move is actu
On Wed, Nov 07, 2018 at 03:34:38PM +0900, Amit Langote wrote:
> On 2018/11/05 16:21, Michael Paquier wrote:
>> On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote:
>>> Done a few moments ago. :)
>>
>> From the file size this move is actually negative. From what I can see
>> partcache dec
Hi,
Thank your for taking a look.
On 2018/11/05 16:21, Michael Paquier wrote:
> On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote:
>> Done a few moments ago. :)
>
> From the file size this move is actually negative. From what I can see
> partcache decreases to 400 lines, while partbo
On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote:
> Done a few moments ago. :)
From the file size this move is actually negative. From what I can see
partcache decreases to 400 lines, while partbounds increases to 3k
lines.
There are a couple of things that this patch is doing:
1) Mo
On 2018/11/01 13:02, Michael Paquier wrote:
> On Thu, Nov 01, 2018 at 12:58:29PM +0900, Amit Langote wrote:
>> Attached find a patch that does such refactoring, along with making some
>> functions in partbounds.c that are not needed outside static.
>
> This looks like a very good idea to me. Than
On Thu, Nov 01, 2018 at 12:58:29PM +0900, Amit Langote wrote:
> Attached find a patch that does such refactoring, along with making some
> functions in partbounds.c that are not needed outside static.
This looks like a very good idea to me. Thanks for digging into that.
Please just make sure to r
21 matches
Mail list logo
