On Tue, Apr 10, 2018 at 7:49 PM, Claudio Freire
wrote:
> On Tue, Apr 10, 2018 at 11:10 AM, Heikki Linnakangas
> wrote:
>
> >
> > Why is this RelationSetTargetBlock() call inside the "XLOG stuff" block?
> > ISTM that we're failing to take advantage of this optimization for
> unlogged
> > tables,
On Tue, Apr 10, 2018 at 11:10 AM, Heikki Linnakangas wrote:
>> /* XLOG stuff */
>> if (RelationNeedsWAL(rel))
>> {
>> ...
>>
>> if (P_ISLEAF(lpageop))
>> {
>>
/* XLOG stuff */
if (RelationNeedsWAL(rel))
{
...
if (P_ISLEAF(lpageop))
{
xlinfo = XLOG_BTREE_INSERT_LEAF;
/*
On Mon, Mar 26, 2018 at 6:06 PM, Pavan Deolasee
wrote:
>
>
> On Sun, Mar 25, 2018 at 6:00 AM, Andrew Dunstan
> wrote:
>>
>> On Fri, Mar 23, 2018 at 8:27 PM, Pavan Deolasee
>> wrote:
>> >>
>> >>
>> >> I would probably just have a few regression lines that should be sure
>> >> to exercise the code
On Sun, Mar 25, 2018 at 6:00 AM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
> On Fri, Mar 23, 2018 at 8:27 PM, Pavan Deolasee
> wrote:
> >>
> >>
> >> I would probably just have a few regression lines that should be sure
> >> to exercise the code path and leave it at that.
> >>
> >
>
On Fri, Mar 23, 2018 at 8:27 PM, Pavan Deolasee
wrote:
>>
>>
>> I would probably just have a few regression lines that should be sure
>> to exercise the code path and leave it at that.
>>
>
> I changed the regression tests to include a few more scenarios, basically
> using multi-column indexes in
Hi Andrew and Claudio,
Thanks for the review!
On Fri, Mar 23, 2018 at 10:19 AM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
> On Fri, Mar 23, 2018 at 10:20 AM, Claudio Freire
> wrote:
>
>
> This patch looks in pretty good shape. I have been trying hard to
> think of some failure mod
On Fri, Mar 23, 2018 at 10:20 AM, Claudio Freire wrote:
> On Thu, Mar 22, 2018 at 3:29 AM, Pavan Deolasee
> wrote:
>>
>> On Thu, Mar 22, 2018 at 7:22 AM, Claudio Freire
>> wrote:
>>>
>>>
>>> If you're not planning on making any further changes, would you mind
>>> posting a coalesced patch?
>>>
>
On Thu, Mar 22, 2018 at 3:29 AM, Pavan Deolasee
wrote:
>
> On Thu, Mar 22, 2018 at 7:22 AM, Claudio Freire
> wrote:
>>
>>
>> If you're not planning on making any further changes, would you mind
>> posting a coalesced patch?
>>
>> Notice that I removed the last offset thing only halfway, so it wou
On Thu, Mar 22, 2018 at 7:22 AM, Claudio Freire
wrote:
>
> If you're not planning on making any further changes, would you mind
> posting a coalesced patch?
>
> Notice that I removed the last offset thing only halfway, so it would
> need some cleanup.
>
Here is an updated patch. I removed the la
On Mon, Mar 19, 2018 at 12:06 PM, Claudio Freire wrote:
> On Mon, Mar 19, 2018 at 11:57 AM, Pavan Deolasee
> wrote:
>>
>>
>> On Thu, Mar 15, 2018 at 7:51 AM, Claudio Freire
>> wrote:
>>>
>>>
>>>
>>> I applied the attached patches on top of your patch, so it would be
>>> nice to see if you can gi
On Mon, Mar 19, 2018 at 11:57 AM, Pavan Deolasee
wrote:
>
>
> On Thu, Mar 15, 2018 at 7:51 AM, Claudio Freire
> wrote:
>>
>>
>>
>> I applied the attached patches on top of your patch, so it would be
>> nice to see if you can give it a try in your test hardware to see
>> whether it helps.
>
>
> I
On Thu, Mar 15, 2018 at 7:51 AM, Claudio Freire
wrote:
>
>
> I applied the attached patches on top of your patch, so it would be
> nice to see if you can give it a try in your test hardware to see
> whether it helps.
>
I can confirm that I no longer see any regression at 8 or even 16 clients.
In
On Wed, Mar 14, 2018 at 12:05 PM, Claudio Freire wrote:
> On Wed, Mar 14, 2018 at 1:36 AM, Pavan Deolasee
> wrote:
>>
>>
>> On Sun, Mar 11, 2018 at 9:18 PM, Claudio Freire
>> wrote:
>>>
>>> On Sun, Mar 11, 2018 at 2:27 AM, Pavan Deolasee
>>>
>>> >
>>> > Yes, I will try that next - it seems like
On Wed, Mar 14, 2018 at 1:36 AM, Pavan Deolasee
wrote:
>
>
> On Sun, Mar 11, 2018 at 9:18 PM, Claudio Freire
> wrote:
>>
>> On Sun, Mar 11, 2018 at 2:27 AM, Pavan Deolasee
>>
>> >
>> > Yes, I will try that next - it seems like a good idea. So the idea would
>> > be:
>> > check if the block is sti
On Wed, Mar 14, 2018 at 7:21 PM, Simon Riggs
wrote:
> On 14 March 2018 at 13:33, Pavan Deolasee
> wrote:
> >
> >
> > On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs <
> simon.ri...@2ndquadrant.com>
> > wrote:
> >>
> >> On 14 March 2018 at 04:36, Pavan Deolasee
> >> wrote:
> >> > I wonder if the sh
On Wed, Mar 14, 2018 at 10:51 AM, Simon Riggs
wrote:
> If there is enough delay in step 1 then any benefit is lost anyway, so
> there is no point taking the cached path even when successful, so its
> better to ignore in that case.
I find myself agreeing with that.
On 14 March 2018 at 13:33, Pavan Deolasee wrote:
>
>
> On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs
> wrote:
>>
>> On 14 March 2018 at 04:36, Pavan Deolasee
>> wrote:
>> > I wonder if the shortened code path actually leads to
>> > heavier contention for EXCLUSIVE lock on the rightmost page, whic
On Wed, Mar 14, 2018 at 4:53 PM, Simon Riggs
wrote:
> On 14 March 2018 at 04:36, Pavan Deolasee
> wrote:
> > I wonder if the shortened code path actually leads to
> > heavier contention for EXCLUSIVE lock on the rightmost page, which in
> turn
> > causes the slowdown. But that's just a theory. A
On 14 March 2018 at 04:36, Pavan Deolasee wrote:
> I wonder if the shortened code path actually leads to
> heavier contention for EXCLUSIVE lock on the rightmost page, which in turn
> causes the slowdown. But that's just a theory. Any ideas how to prove or
> disprove that theory or any other point
On Wed, Mar 14, 2018 at 10:58 AM, Claudio Freire
wrote:
>
>
> I'm thinking there could be contention on some lock somewhere.
>
> Can you attach the benchmark script you're using so I can try to reproduce
> it?
>
I am using a very ad-hoc script.. But here it is.. It assumes a presence of
a branc
On Wed, Mar 14, 2018 at 1:36 AM, Pavan Deolasee
wrote:
>
>
> On Sun, Mar 11, 2018 at 9:18 PM, Claudio Freire
> wrote:
>>
>> On Sun, Mar 11, 2018 at 2:27 AM, Pavan Deolasee
>>
>> >
>> > Yes, I will try that next - it seems like a good idea. So the idea would
>> > be:
>> > check if the block is sti
On Sun, Mar 11, 2018 at 9:18 PM, Claudio Freire
wrote:
> On Sun, Mar 11, 2018 at 2:27 AM, Pavan Deolasee
>
> >
> > Yes, I will try that next - it seems like a good idea. So the idea would
> be:
> > check if the block is still the rightmost block and the insertion-key is
> > greater than the first
On Sun, Mar 11, 2018 at 2:27 AM, Pavan Deolasee
wrote:
>
>
> On Sat, Mar 10, 2018 at 12:11 AM, Claudio Freire
> wrote:
>>
>> On Fri, Mar 9, 2018 at 2:54 PM, Pavan Deolasee
>> wrote:
>> >
>> >
>>
>> >
>> > So yes, the benefits of the patch go down with higher number of clients,
>> > but
>> > it d
On Sat, Mar 10, 2018 at 12:11 AM, Claudio Freire
wrote:
> On Fri, Mar 9, 2018 at 2:54 PM, Pavan Deolasee
> wrote:
> >
> >
>
> >
> > So yes, the benefits of the patch go down with higher number of clients,
> but
> > it does not entirely vanish.
>
> What if you implement my suggestion?
>
> That sh
On Fri, Mar 9, 2018 at 2:54 PM, Pavan Deolasee wrote:
>
>
> On Tue, Mar 6, 2018 at 10:10 AM, Pavan Deolasee
> wrote:
>>
>>
>>
>> On Tue, Mar 6, 2018 at 7:29 AM, Peter Geoghegan wrote:
>>>
>>> On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire
>>> wrote:
>>>
>>> > I believe PKs are a prime candidate
On Tue, Mar 6, 2018 at 10:10 AM, Pavan Deolasee
wrote:
>
>
> On Tue, Mar 6, 2018 at 7:29 AM, Peter Geoghegan wrote:
>
>> On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire
>> wrote:
>>
>> > I believe PKs are a prime candidate for this optimization, and
>> > expecting it to apply only when no concur
On Tue, Mar 6, 2018 at 9:06 AM, Simon Riggs wrote:
>> Simon had raised concerns about DESC indexes and whether we need to do the
>> checks for leftmost page in that case. I haven't yet figured out if DESC
>> indexes are actually stored in the reverse order. I am gonna look at that
>> too.
>
> No,
On 6 March 2018 at 04:40, Pavan Deolasee wrote:
>
>
> On Tue, Mar 6, 2018 at 7:29 AM, Peter Geoghegan wrote:
>>
>> On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire
>> wrote:
>>
>> > I believe PKs are a prime candidate for this optimization, and
>> > expecting it to apply only when no concurrency i
On Tue, Mar 6, 2018 at 1:45 AM, Peter Geoghegan wrote:
> On Mon, Mar 5, 2018 at 7:10 PM, Claudio Freire wrote:
>>> Introducing any case that allows us to land on a recycled page, and
>>> reason that it must at least not be the page we were looking for based
>>> on *any* criteria about the page it
On Mon, Mar 5, 2018 at 7:10 PM, Claudio Freire wrote:
>> Introducing any case that allows us to land on a recycled page, and
>> reason that it must at least not be the page we were looking for based
>> on *any* criteria about the page itself seems very brittle. Yeah, it
>> probably won't break in
On Tue, Mar 6, 2018 at 7:29 AM, Peter Geoghegan wrote:
> On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire
> wrote:
>
> > I believe PKs are a prime candidate for this optimization, and
> > expecting it to apply only when no concurrency is involved is severely
> > dumbing down the optimization.
>
>
On Mon, Mar 5, 2018 at 10:59 PM, Peter Geoghegan wrote:
> On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire wrote:
>> But in thise case there's no right link to follow, so it's a non-issue.
>>
>> BTree doesn't truncate AFAIK, so the cached block number can't be
>> nonexisting (beyond the end of the
On Mon, Mar 5, 2018 at 5:48 PM, Claudio Freire wrote:
> From what I read, both phase 1 & 2 are served by the !P_IGNORE check.
True.
> For the third phase:
>
>> A deleted page can only be reclaimed once there is no scan or search that
>> has a reference to it; until then, it must stay in place wi
On Mon, Mar 5, 2018 at 9:52 PM, Peter Geoghegan wrote:
> On Mon, Mar 5, 2018 at 4:37 PM, Claudio Freire wrote:
>> Correct me if I'm wrong, but there's lots of code in nbtree already
>> that risks reading recycled pages for various reasons. Presumably,
>> checking P_ISDELETED and P_ISHALFDEAD shou
On Mon, Mar 5, 2018 at 4:37 PM, Claudio Freire wrote:
> Correct me if I'm wrong, but there's lots of code in nbtree already
> that risks reading recycled pages for various reasons. Presumably,
> checking P_ISDELETED and P_ISHALFDEAD should be enough, which is what
> !P_IGNORE implies.
You're mist
On Mon, Mar 5, 2018 at 9:37 PM, Claudio Freire wrote:
> Assuming the rightmost page is the first page the value could be on,
> it already does get an exclusive buffer lock.
That made me check, and:
+/*
+ * Acquire exclusive lock on the buffer before doing any checks. This
+
On Mon, Mar 5, 2018 at 9:12 PM, Peter Geoghegan wrote:
> On Thu, Mar 1, 2018 at 3:18 PM, Claudio Freire wrote:
>> The key there is strictly greater than the rightmost key. As such, it
>> must precede the first page with an equal key, and since it's the
>> rightmost page... there's no such key. Bu
On Thu, Mar 1, 2018 at 3:18 PM, Claudio Freire wrote:
> given...
>
> +if (P_ISLEAF(lpageop) && P_RIGHTMOST(lpageop) &&
> +!P_INCOMPLETE_SPLIT(lpageop) &&
> +!P_IGNORE(lpageop) &&
> +(PageGetFreeSpace(page) > itemsz) &&
> +_bt_compare(rel, nat
On Sun, Dec 31, 2017 at 8:06 AM, Peter Geoghegan wrote:
> I also have my
> doubts about unique index enforcement remaining correct with the patch
> when there are many physical duplicates, to the extent that more than
> a single leaf page is needed for a single value.
given...
+if (P_ISL
On 31 December 2017 at 11:06, Peter Geoghegan wrote:
> On Sun, Dec 31, 2017 at 6:44 AM, Pavan Deolasee
> wrote:
>> Here is a patch that implements the idea. If the last insert happens to be
>> in the rightmost block of an index, then we cache the block and check that
>> first for the next insert.
On Thu, Jan 4, 2018 at 6:05 PM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
> > On Tue, Jan 2, 2018 at 7:15 PM, Tels
> wrote:
> >
> > > Just a question trying to understand how btree indexes work:
> > >
> > > If one inserts ever-increasing value, is the tree a balanced tree with
> a
> > > mini
Hello Alvaro,
On Thu, January 4, 2018 7:35 am, Alvaro Herrera wrote:
> Pavan Deolasee wrote:
>> On Tue, Jan 2, 2018 at 7:15 PM, Tels
>> wrote:
>>
>> > Just a question trying to understand how btree indexes work:
>> >
>> > If one inserts ever-increasing value, is the tree a balanced tree with
>> a
Pavan Deolasee wrote:
> On Tue, Jan 2, 2018 at 7:15 PM, Tels wrote:
>
> > Just a question trying to understand how btree indexes work:
> >
> > If one inserts ever-increasing value, is the tree a balanced tree with a
> > minimum (or at least not-as-high) number of levels, or does it increase in
>
On Tue, Jan 2, 2018 at 7:15 PM, Tels wrote:
> Moin,
>
>
> >>
> >>
> > Hmm Ok. I am not entirely sure whether it's the depth or just purely
> > binary
> > searching through 3-4 index pages and/or pinning/unpinning buffers result
> > in much overhead. I will run some more tests and collect evidence
Moin,
On Tue, January 2, 2018 7:51 am, Pavan Deolasee wrote:
> On Sun, Dec 31, 2017 at 4:36 PM, Peter Geoghegan wrote:
>
>> On Sun, Dec 31, 2017 at 6:44 AM, Pavan Deolasee
>> wrote:
>> > Here is a patch that implements the idea. If the last insert happens
>> to
>> be
>> > in the rightmost block
On Sun, Dec 31, 2017 at 4:36 PM, Peter Geoghegan wrote:
> On Sun, Dec 31, 2017 at 6:44 AM, Pavan Deolasee
> wrote:
> > Here is a patch that implements the idea. If the last insert happens to
> be
> > in the rightmost block of an index, then we cache the block and check
> that
> > first for the n
Hi!
> 31 дек. 2017 г., в 11:44, Pavan Deolasee
> написал(а):
> On a per-session basis, we cache the last heap block used for inserts and try
> to use the same block for subsequent inserts.
+1, from my POV this is good idea and it's cool that it already has
implementation.
I'd suggest to do not
On Sun, Dec 31, 2017 at 6:44 AM, Pavan Deolasee
wrote:
> Here is a patch that implements the idea. If the last insert happens to be
> in the rightmost block of an index, then we cache the block and check that
> first for the next insert. For the cached block to be usable for the insert,
> it shoul
Hello All,
On a per-session basis, we cache the last heap block used for inserts and
try to use the same block for subsequent inserts. We don't do that for
indexes because the target block in the index is determined by the overall
structure of the index and the index key being inserted and hence c
50 matches
Mail list logo
