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

pgsql: Optimize btree insertions for common case of increasing values

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 long as we can get a lock on the page. Otherwise, fall back on