Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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 >>

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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 > >

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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()

Re: pgsql: Optimize btree insertions for common case of increasing values

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 >>>

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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

Re: pgsql: Optimize btree insertions for common case of increasing values

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