On Tue, Apr 10, 2018 at 3:37 PM, Andrew Dunstan
wrote:
>> The comments still say "Check if the page...no split is in progress".
>> Despite the fact that that's just an assertion now.
>>
>
> Fixed.
Thanks.
--
Peter Geoghegan
On 04/10/2018 06:33 PM, Peter Geoghegan wrote:
> On Tue, Apr 10, 2018 at 3:27 PM, Andrew Dunstan wrote:
>> Committed with light editing. I didn't put the #define in the .h file -
>> it's only used here and that seemed like unnecessary clutter. I moved it
>> to the top of the file. I also standar
On Tue, Apr 10, 2018 at 3:27 PM, Andrew Dunstan wrote:
> Committed with light editing. I didn't put the #define in the .h file -
> it's only used here and that seemed like unnecessary clutter. I moved it
> to the top of the file. I also standardized the spelling of "optimization".
The comments st
On 04/10/2018 03:30 PM, Peter Geoghegan wrote:
> On Tue, Apr 10, 2018 at 12:07 PM, Pavan Deolasee
> wrote:
>> Hmm. I am a bit confused why we want to mention anything about something
>> we're not even considering seriously, let alone any patch or work in that
>> direction. If we at all change ev
On Tue, Apr 10, 2018 at 12:30 PM, Peter Geoghegan wrote:
>> Apart from that, other changes requested are included in the patch. This
>> also takes care of Heikki's observation regarding UNLOGGED tables on the
>> other thread.
>
> Cool.
BTW, Heikki's commit didn't remove the "no split is in progr
On Tue, Apr 10, 2018 at 12:07 PM, Pavan Deolasee
wrote:
> Hmm. I am a bit confused why we want to mention anything about something
> we're not even considering seriously, let alone any patch or work in that
> direction. If we at all change everything to use extent based storage, there
> would be m
On Tue, Apr 10, 2018 at 1:18 AM, Peter Geoghegan wrote:
> On Thu, Apr 5, 2018 at 10:16 AM, Peter Geoghegan wrote:
> > I think you can take that wording almost verbatim. Obviously it should
> > refer to the optimization by name, and blend into the surrounding text
> > in the README. I suggest put
On Thu, Apr 5, 2018 at 10:16 AM, Peter Geoghegan wrote:
> I think you can take that wording almost verbatim. Obviously it should
> refer to the optimization by name, and blend into the surrounding text
> in the README. I suggest putting a small section before "On-the-Fly
> Deletion Of Index Tuples
On Thu, Apr 5, 2018 at 6:27 AM, Pavan Deolasee wrote:
> I came up with something like this:
>
> + /*
> +* If we're here then a pagesplit is needed. We should never
> reach here
> +* if we're using the fastpath since we should have checked
> for all the
On Wed, Apr 4, 2018 at 10:46 PM, Peter Geoghegan wrote:
>
>
> > You mean passing "fastpath" to _bt_insertonpg and then checking it's
> false
> > if page split is needed? But isn't page split is only needed if the page
> > doesn't have enough free space? If so, we have checked for that before
> >
On Wed, Apr 4, 2018 at 5:33 AM, Pavan Deolasee wrote:
> Ok. Adding a check for tree height and setting target block only if it's >=
> 2, as suggested by you and Simon later. Rahila helped me also ran another
> round of tests and this does not lead to any performance regression (we were
> worried a
On Thu, Mar 29, 2018 at 4:39 AM, Peter Geoghegan wrote:
>
>
> Suggested next steps to deal with this:
>
> * A minor point: I don't think you should call
> RelationSetTargetBlock() when the page P_ISROOT(), which, as I
> mentioned, is a condition that can coexist with P_ISLEAF() with very
> small
On Thu, Mar 29, 2018 at 7:59 AM, Simon Riggs wrote:
>> Another issue that I have with the main test of the
>> RelationSetTargetBlock() page is that nobody explains *why* we check
>> that we have enough space on the page to proceed. Why would it not be
>> okay if there was a page split?
>
> ...beca
On 29 March 2018 at 00:09, Peter Geoghegan wrote:
> On Wed, Mar 28, 2018 at 11:56 AM, Peter Geoghegan wrote:
>>> Previously, we agreed that P_IGNORE() is required. So I assume no issues
>>> there. The other tests seem required too for us to conclusively decide to
>>> use the cached block.
>>
>> A
On Wed, Mar 28, 2018 at 11:56 AM, Peter Geoghegan wrote:
>> Previously, we agreed that P_IGNORE() is required. So I assume no issues
>> there. The other tests seem required too for us to conclusively decide to
>> use the cached block.
>
> Actually, you're right that P_INCOMPLETE_SPLIT() is the onl
On Wed, Mar 28, 2018 at 2:14 AM, Pavan Deolasee
wrote:
>> This code can allocate memory in a critical section, since
>> RelationSetTargetBlock() can call smgropen():
> I think you're right. I propose that we call RelationSetTargetBlock right
> after the critical section ends. That should not have
On Wed, Mar 28, 2018 at 11:33 AM, Peter Geoghegan wrote:
>
>
> This code can allocate memory in a critical section, since
> RelationSetTargetBlock() can call smgropen():
>
> if (P_ISLEAF(lpageop))
> + {
> xlinfo = XLOG_BTREE_INSERT_LEAF;
> +
> +
On Mon, Mar 26, 2018 at 5:10 AM, Andrew Dunstan wrote:
> Optimize btree insertions for common case of increasing values
>
> Remember the last page of an index insert if it's the rightmost leaf
> page. If the next entry belongs on and can fit in the remembered page,
> insert the new entry there as
18 matches
Mail list logo
