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
49 matches
Mail list logo
