On Fri, Mar 22, 2019 at 2:15 PM Peter Geoghegan wrote:
> On Thu, Mar 21, 2019 at 10:28 AM Peter Geoghegan wrote:
> > I'll likely push the remaining two patches on Sunday or Monday.
>
> I noticed that if I initidb and run "make installcheck" with and
> without the "split after new tuple" optimizat
On Thu, Mar 21, 2019 at 10:28 AM Peter Geoghegan wrote:
> I've committed the first 4 patches. Many thanks to Heikki for his very
> valuable help! Thanks also to the other reviewers.
>
> I'll likely push the remaining two patches on Sunday or Monday.
I noticed that if I initidb and run "make insta
On Tue, Mar 19, 2019 at 4:15 PM Peter Geoghegan wrote:
> Heikki and I discussed this issue privately, over IM, and reached
> final agreement on remaining loose ends. I'm going to use his code for
> _bt_findsplitloc(). Plan to push a final version of the first four
> patches tomorrow morning PST.
On Mon, Mar 18, 2019 at 10:17 AM Peter Geoghegan wrote:
> The big difference is that you make the possible call to
> _bt_stepright() conditional on this being a checkingunique index --
> the duplicate code is indented in that branch of _bt_findsplitloc().
> Whereas I break early in the loop when "
On Mon, Mar 18, 2019 at 5:12 PM Peter Geoghegan wrote:
> Smarter choices on page splits pay off with higher client counts
> because they reduce contention at likely hot points. It's kind of
> crazy that the code in _bt_check_unique() sometimes has to move right,
> while holding an exclusive buffer
On Mon, Mar 18, 2019 at 5:00 PM Robert Haas wrote:
> Blech. I think the patch has enough other advantages that it's worth
> accepting that, but it's not great. We seem to keep finding reasons
> to reduce single client performance in the name of scalability, which
> is often reasonable not but wo
On Mon, Mar 18, 2019 at 7:34 PM Peter Geoghegan wrote:
> With pgbench scale factor 20, here are results for patch and master
> with a Gaussian distribution on my 8 thread/4 core home server, with
> each run reported lasting 10 minutes, repeating twice for client
> counts 1, 2, 8, 16, and 64, patch
On Tue, Mar 12, 2019 at 11:40 AM Robert Haas wrote:
> I think it's pretty clear that we have to view that as acceptable. I
> mean, we could reduce contention even further by finding a way to make
> indexes 40% larger, but I think it's clear that nobody wants that.
> Now, maybe in the future we'll
On Mon, Mar 18, 2019 at 4:59 AM Heikki Linnakangas wrote:
> I'm getting a regression failure from the 'create_table' test with this:
> Are you seeing that?
Yes -- though the bug is in your revised v18, not the original v18,
which passed CFTester. Your revision fails on Travis/Linux, which is
pre
On Sat, Mar 16, 2019 at 2:01 PM Peter Geoghegan wrote:
>
> On Sat, Mar 16, 2019 at 1:47 PM Peter Geoghegan wrote:
> > I agree that it's always true that the high key is also in the parent,
> > and we could cross-check that within the child. Actually, I should
> > probably figure out a way of arra
On Sat, Mar 16, 2019 at 1:47 PM Peter Geoghegan wrote:
> I agree that it's always true that the high key is also in the parent,
> and we could cross-check that within the child. Actually, I should
> probably figure out a way of arranging for the Bloom filter used
> within bt_relocate_from_root() (
On Sat, Mar 16, 2019 at 1:33 PM Heikki Linnakangas wrote:
> AFAICS, there is a copy of every page's high key in its immediate
> parent. Either in the downlink of the right sibling, or as the high key
> of the parent page itself. Cross-checking those would catch any
> corruption in high keys.
I ag
On 16/03/2019 18:55, Peter Geoghegan wrote:
On Sat, Mar 16, 2019 at 9:17 AM Heikki Linnakangas wrote:
Then, a cosmic ray changes the 20 on the root page to 18. That causes
the the leaf tuple 19 to become non-re-findable; if you descend the for
19, you'll incorrectly land on page 6. But it also
On 16/03/2019 19:32, Peter Geoghegan wrote:
On Sat, Mar 16, 2019 at 9:55 AM Peter Geoghegan wrote:
On Sat, Mar 16, 2019 at 9:17 AM Heikki Linnakangas wrote:
Hmm. "re-find", maybe? We use that term in a few error messages already,
to mean something similar.
WFM.
Actually, how about "rootse
On Sat, Mar 16, 2019 at 9:55 AM Peter Geoghegan wrote:
> On Sat, Mar 16, 2019 at 9:17 AM Heikki Linnakangas wrote:
> > Hmm. "re-find", maybe? We use that term in a few error messages already,
> > to mean something similar.
>
> WFM.
Actually, how about "rootsearch", or "rootdescend"? You're suppo
On Sat, Mar 16, 2019 at 9:17 AM Heikki Linnakangas wrote:
> Hmm. "re-find", maybe? We use that term in a few error messages already,
> to mean something similar.
WFM.
> At first, I thought this would be horrendously expensive, but thinking
> about it a bit more, nearby tuples will always follow
On 16/03/2019 10:51, Peter Geoghegan wrote:
On Sat, Mar 16, 2019 at 1:44 AM Heikki Linnakangas wrote:
It would be nice if you could take a look at the amcheck "relocate"
patch
When I started looking at this, I thought that "relocate" means "move".
So I thought that the new mode would actually
On Sat, Mar 16, 2019 at 1:44 AM Heikki Linnakangas wrote:
> > It would be nice if you could take a look at the amcheck "relocate"
> > patch
> When I started looking at this, I thought that "relocate" means "move".
> So I thought that the new mode would actually move tuples, i.e. that it
> would mo
On 16/03/2019 06:16, Peter Geoghegan wrote:
On Thu, Mar 14, 2019 at 2:21 AM Heikki Linnakangas wrote:
It doesn't matter how often it happens, the code still needs to deal
with it. So let's try to make it as readable as possible.
Well, IMHO holding the buffer and the bounds in the new struct
On Thu, Mar 14, 2019 at 4:00 AM Heikki Linnakangas wrote:
> Oh yeah, that makes perfect sense. I wonder why we haven't done it like
> that before? The new page split logic makes it more likely to help, but
> even without that, I don't see any downside.
The only downside is that we spend a few ext
On 13/03/2019 03:28, Peter Geoghegan wrote:
It would be great if you could take a look at the 'Add high key
"continuescan" optimization' patch, which is the only one you haven't
commented on so far (excluding the amcheck "relocate" patch, which is
less important). I can put that one off for a whi
On 13/03/2019 03:28, Peter Geoghegan wrote:
On Wed, Mar 6, 2019 at 10:15 PM Heikki Linnakangas wrote:
I made a copy of the _bt_binsrch, _bt_binsrch_insert. It does the binary
search like _bt_binsrch does, but the bounds caching is only done in
_bt_binsrch_insert. Seems more clear to have separa
On Tue, Mar 12, 2019 at 11:40 AM Robert Haas wrote:
> I think it's pretty clear that we have to view that as acceptable. I
> mean, we could reduce contention even further by finding a way to make
> indexes 40% larger, but I think it's clear that nobody wants that.
I found this analysis of bloat
On Wed, Mar 6, 2019 at 10:15 PM Heikki Linnakangas wrote:
> I made a copy of the _bt_binsrch, _bt_binsrch_insert. It does the binary
> search like _bt_binsrch does, but the bounds caching is only done in
> _bt_binsrch_insert. Seems more clear to have separate functions for them
> now, even though
On Tue, Mar 12, 2019 at 2:22 PM Andres Freund wrote:
> I'm basically just curious which buffers have most of the additional
> contention. Is it the lower number of leaf pages, the inner pages, or
> (somewhat unexplicably) the meta page, or ...? I was thinking that the
> callstack that e.g. my lwl
On 2019-03-12 14:15:06 -0700, Peter Geoghegan wrote:
> On Tue, Mar 12, 2019 at 12:40 PM Andres Freund wrote:
> > Have you looked at an offwake or lwlock wait graph (bcc tools) or
> > something in that vein? Would be interesting to see what is waiting for
> > what most often...
>
> Not recently, t
On Tue, Mar 12, 2019 at 12:40 PM Andres Freund wrote:
> Have you looked at an offwake or lwlock wait graph (bcc tools) or
> something in that vein? Would be interesting to see what is waiting for
> what most often...
Not recently, though I did use your BCC script for this very purpose
quite a few
Hi,
On 2019-03-11 19:47:29 -0700, Peter Geoghegan wrote:
> I now believe that the problem is with LWLock/buffer lock contention
> on index pages, and that that's an inherent cost with a minority of
> write-heavy high contention workloads. A cost that we should just
> accept.
Have you looked at an
On Tue, Mar 12, 2019 at 11:40 AM Robert Haas wrote:
> Hey, I understood something today!
And I said something that could be understood!
> I think it's pretty clear that we have to view that as acceptable. I
> mean, we could reduce contention even further by finding a way to make
> indexes 40% l
On Tue, Mar 12, 2019 at 2:34 PM Peter Geoghegan wrote:
> On Tue, Mar 12, 2019 at 11:32 AM Robert Haas wrote:
> > If I wanted to try to say this in fewer words, would it be fair to say
> > that reducing the size of an index by 40% without changing anything
> > else can increase contention on the r
On Tue, Mar 12, 2019 at 11:32 AM Robert Haas wrote:
> If I wanted to try to say this in fewer words, would it be fair to say
> that reducing the size of an index by 40% without changing anything
> else can increase contention on the remaining pages?
Yes.
--
Peter Geoghegan
On Mon, Mar 11, 2019 at 10:47 PM Peter Geoghegan wrote:
>
> On Sun, Mar 10, 2019 at 5:17 PM Peter Geoghegan wrote:
> > The regression that I mentioned earlier isn't in pgbench type
> > workloads (even when the distribution is something more interesting
> > that the uniform distribution default).
On Mon, Mar 11, 2019 at 11:30 PM Heikki Linnakangas wrote:
> Yeah, that's fine. I'm curious, though, could you bloat the indexes back
> to the old size by setting the fillfactor?
I think that that might work, though it's hard to say for sure offhand.
The "split after new item" optimization is su
On 12/03/2019 04:47, Peter Geoghegan wrote:
In conclusion: I think that this regression is a cost worth accepting.
The regression in throughput is relatively small (2% - 3%), and the
NEW_ORDER transaction seems to be the only problem (NEW_ORDER happens
to be used for 45% of all transactions with
On Sun, Mar 10, 2019 at 12:53 PM Heikki Linnakangas wrote:
> Ah, yeah. Not sure. I wrote it as "searching_for_pivot_tuple" first, but
> changed to "searching_for_leaf_page" at the last minute. My thinking was
> that in the page-deletion case, you're trying to re-locate a particular
> leaf page. Ot
On 10/03/2019 20:53, Peter Geoghegan wrote:
On Sun, Mar 10, 2019 at 7:09 AM Heikki Linnakangas wrote:
If we don't flip the meaning of the flag, then maybe calling it
something like "searching_for_leaf_page" would make sense:
/*
* When set, we're searching for the leaf page with the given hi
On Sun, Mar 10, 2019 at 7:09 AM Heikki Linnakangas wrote:
> "descendrighttrunc" doesn't make much sense to me, either. I don't
> understand it. Maybe a comment would make it clear, though.
It's not an easily grasped concept. I don't think that any name will
easily convey the idea to the reader, t
On 08/03/2019 23:21, Peter Geoghegan wrote:
On Fri, Mar 8, 2019 at 10:48 AM Peter Geoghegan wrote:
All of that said, maybe it would be clearer if page deletion was not
the special case that has to opt in to minusinfkey semantics. Perhaps
it would make more sense for everyone else to opt out of
On Fri, Mar 8, 2019 at 10:48 AM Peter Geoghegan wrote:
> All of that said, maybe it would be clearer if page deletion was not
> the special case that has to opt in to minusinfkey semantics. Perhaps
> it would make more sense for everyone else to opt out of minusinfkey
> semantics, and to get the !
On Fri, Mar 8, 2019 at 10:48 AM Peter Geoghegan wrote:
> > Question: Wouldn't it be more straightforward to use "1 +inf" as page
> > 1's high key? I.e treat any missing columns as positive infinity.
>
> That might also work, but it wouldn't be more straightforward on
> balance. This is because:
I
On Fri, Mar 8, 2019 at 2:12 AM Heikki Linnakangas wrote:
> Now, what do we have as the high key of page 1? Answer: "2 -inf". The
> "-inf" is not stored in the key itself, the second key column is just
> omitted, and the search code knows to treat it implicitly as a value
> that's lower than any re
On 08/03/2019 12:22, Peter Geoghegan wrote:
I would like to work through these other items with you
(_bt_binsrch_insert() and so on), but I think that it would be helpful
if you made an effort to understand the minusinfkey stuff first. I
spent a lot of time improving the explanation of that withi
On Wed, Mar 6, 2019 at 11:41 PM Heikki Linnakangas wrote:
> I don't understand it :-(. I guess that's valuable feedback on its own.
> I'll spend more time reading the code around that, but meanwhile, if you
> can think of a simpler way to explain it in the comments, that'd be good.
One more thing
On Thu, Mar 7, 2019 at 12:37 AM Peter Geoghegan wrote:
> When I drew you that picture while we were in Lisbon, I mentioned to
> you that the patch sometimes used a sentinel scantid value that was
> greater than minus infinity, but less than any real scantid. This
> could be used to force an otherw
On Wed, Mar 6, 2019 at 11:41 PM Heikki Linnakangas wrote:
> > BTW, I would like to hear what you think of the idea of minusinfkey
> > (and the !minusinfkey optimization) specifically.
>
> I don't understand it :-(. I guess that's valuable feedback on its own.
> I'll spend more time reading the cod
On Thu, Mar 7, 2019 at 12:14 AM Heikki Linnakangas wrote:
> I haven't investigated any deeper, but apparently something's broken.
> This was with patch v14, without any further changes.
Try it with my patch -- attached.
I think that you missed that the INCLUDE indexes thing within
nbtsort.c need
On 05/03/2019 05:16, Peter Geoghegan wrote:
Attached is v14, which has changes based on your feedback.
As a quick check of the backwards-compatibility code, i.e.
!heapkeyspace, I hacked _bt_initmetapage to force the version number to
3, and ran the regression tests. It failed an assertion in th
On 07/03/2019 15:41, Heikki Linnakangas wrote:
On 07/03/2019 14:54, Peter Geoghegan wrote:
On Wed, Mar 6, 2019 at 10:15 PM Heikki Linnakangas wrote:
After staring at the first patch for bit longer, a few things started to
bother me:
* The new struct is called BTScanInsert, but it's used for s
On 07/03/2019 14:54, Peter Geoghegan wrote:
On Wed, Mar 6, 2019 at 10:15 PM Heikki Linnakangas wrote:
After staring at the first patch for bit longer, a few things started to
bother me:
* The new struct is called BTScanInsert, but it's used for searches,
too. It makes sense when you read the R
On Wed, Mar 6, 2019 at 10:54 PM Peter Geoghegan wrote:
> It will also have to store heapkeyspace, of course. And minusinfkey.
> BTW, I would like to hear what you think of the idea of minusinfkey
> (and the !minusinfkey optimization) specifically.
> I'm not sure that that's an improvement. Moving
On Wed, Mar 6, 2019 at 10:15 PM Heikki Linnakangas wrote:
> After staring at the first patch for bit longer, a few things started to
> bother me:
>
> * The new struct is called BTScanInsert, but it's used for searches,
> too. It makes sense when you read the README, which explains the
> difference
On 06/03/2019 04:03, Peter Geoghegan wrote:
On Tue, Mar 5, 2019 at 3:37 AM Heikki Linnakangas wrote:
I'm looking at the first patch in the series now. I'd suggest that you
commit that very soon. It's useful on its own, and seems pretty much
ready to be committed already. I don't think it will b
On Wed, Mar 6, 2019 at 1:37 PM Robert Haas wrote:
> I know I'm stating the obvious here, but we don't have many weeks left
> at this point. I have not reviewed any code, but I have been
> following this thread and I'd really like to see this work go into
> PostgreSQL 12, assuming it's in good eno
On Tue, Mar 5, 2019 at 3:03 PM Peter Geoghegan wrote:
> I agree that the parts covered by the first patch in the series are
> very unlikely to need changes, but I hesitate to commit it weeks ahead
> of the other patches.
I know I'm stating the obvious here, but we don't have many weeks left
at th
On Tue, Mar 5, 2019 at 3:37 AM Heikki Linnakangas wrote:
> I'm looking at the first patch in the series now. I'd suggest that you
> commit that very soon. It's useful on its own, and seems pretty much
> ready to be committed already. I don't think it will be much affected by
> whatever changes we
I'm looking at the first patch in the series now. I'd suggest that you
commit that very soon. It's useful on its own, and seems pretty much
ready to be committed already. I don't think it will be much affected by
whatever changes we make to the later patches, anymore.
I did some copy-editing o
On Sun, Mar 3, 2019 at 10:02 PM Heikki Linnakangas wrote:
> Some comments on
> v13-0002-make-heap-TID-a-tie-breaker-nbtree-index-column.patch below.
> Mostly about code comments. In general, I think a round of copy-editing
> the comments, to use simpler language, would do good. The actual code
> c
Some comments on
v13-0002-make-heap-TID-a-tie-breaker-nbtree-index-column.patch below.
Mostly about code comments. In general, I think a round of copy-editing
the comments, to use simpler language, would do good. The actual code
changes look good to me.
/*
* _bt_findinsertloc() -- Find
On 26/02/2019 12:31, Peter Geoghegan wrote:
On Mon, Jan 28, 2019 at 7:32 AM Heikki Linnakangas wrote:
I spent some time first trying to understand the current algorithm, and
then rewriting it in a way that I find easier to understand. I came up
with the attached. I think it optimizes for the sa
On Mon, Feb 11, 2019 at 12:54 PM Peter Geoghegan wrote:
> Notable improvements in v12:
I've been benchmarking v12, once again using a slightly modified
BenchmarkSQL that doesn't do up-front CREATE INDEX builds [1], since
the problems with index bloat don't take so long to manifest
themselves when
On Mon, Jan 28, 2019 at 1:41 PM Peter Geoghegan wrote:
> Thanks for going to the trouble of implementing what you have in mind!
>
> I agree that the code that I wrote within nbtsplitloc.c is very
> subtle, and I do think that I have further work to do to make its
> design clearer. I think that thi
On Mon, Jan 28, 2019 at 7:32 AM Heikki Linnakangas wrote:
> I spent some time first trying to understand the current algorithm, and
> then rewriting it in a way that I find easier to understand. I came up
> with the attached. I think it optimizes for the same goals as your
> patch, but the approac
On 09/01/2019 02:47, Peter Geoghegan wrote:
On Fri, Dec 28, 2018 at 3:32 PM Peter Geoghegan wrote:
On Fri, Dec 28, 2018 at 3:20 PM Heikki Linnakangas wrote:
I'm envisioning that you have an array, with one element for each item
on the page (including the tuple we're inserting, which isn't rea
Hi Alexander,
On Fri, Jan 4, 2019 at 7:40 AM Alexander Korotkov
wrote:
> I'm starting to look at this patchset. Not ready to post detail
> review, but have a couple of questions.
Thanks for taking a look!
> Yes, it shouldn't be too hard, but it seems like we have to keep two
> branches of code
Hi!
I'm starting to look at this patchset. Not ready to post detail
review, but have a couple of questions.
On Wed, Sep 19, 2018 at 9:24 PM Peter Geoghegan wrote:
> I still haven't managed to add pg_upgrade support, but that's my next
> step. I am more or less happy with the substance of the pa
On Fri, Dec 28, 2018 at 3:20 PM Heikki Linnakangas wrote:
> Right. You'll need to do the free space computations from left to right,
> but once you have done that, you can compute the penalties in any order.
>
> I'm envisioning that you have an array, with one element for each item
> on the page (
On 29/12/2018 01:04, Peter Geoghegan wrote:
However, naively computing the penalty upfront for every offset would be
a bit wasteful. Instead, start from the middle of the page, and walk
"outwards" towards both ends, until you find a "good enough" penalty.
You can't start at the middle of the pa
On Fri, Dec 28, 2018 at 10:04 AM Heikki Linnakangas wrote:
> I spent some time reviewing this. I skipped the first patch, to add a
> column to pg_depend, and I got through patches 2, 3 and 4. Impressive
> results, and the code looks sane.
Thanks! I really appreciate your taking the time to do suc
On 04/12/2018 05:10, Peter Geoghegan wrote:
Attached is v9, ...
I spent some time reviewing this. I skipped the first patch, to add a
column to pg_depend, and I got through patches 2, 3 and 4. Impressive
results, and the code looks sane.
I wrote a laundry list of little comments on minor th
On Mon, Dec 3, 2018 at 7:10 PM Peter Geoghegan wrote:
> Attached is v9, which does things that way. There are no interesting
> changes, though I have set things up so that a later patch in the
> series can add "dynamic prefix truncation" -- I do not include any
> such patch in v9, though. I'm goin
On Sat, Dec 1, 2018 at 4:10 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Just for the information, cfbot says there are problems on windows:
>
> src/backend/catalog/pg_depend.c(33): error C2065: 'INT32_MAX' :
> undeclared identifier
Thanks. Looks like I should have used PG_INT32_MAX.
--
Pet
> On Sun, Nov 25, 2018 at 12:14 AM Peter Geoghegan wrote:
>
> Attached is v8 of the patch series, which has some relatively minor changes:
Thank you for working on this patch,
Just for the information, cfbot says there are problems on windows:
src/backend/catalog/pg_depend.c(33): error C2065: '
On Sun, Nov 4, 2018 at 8:21 AM Andrey Lepikhov
wrote:
> I mean that your code have not any problems that I can detect by
> regression tests and by the retail index tuple deletion patch.
> Difference in amount of dropped objects is not a problem. It is caused
> by pos 2293 - 'else if (thisobj->obje
On 04.11.2018 9:31, Peter Geoghegan wrote:
On Sat, Nov 3, 2018 at 8:52 PM Andrey Lepikhov
wrote:
I applied your patches at top of master. After tests corrections
(related to TID ordering in index relations DROP...CASCADE operation)
'make check-world' passed successfully many times.
In the ca
On Sat, Nov 3, 2018 at 8:52 PM Andrey Lepikhov
wrote:
> I applied your patches at top of master. After tests corrections
> (related to TID ordering in index relations DROP...CASCADE operation)
> 'make check-world' passed successfully many times.
> In the case of 'create view' regression test - 'dr
On Fri, Nov 2, 2018 at 5:00 PM Peter Geoghegan wrote:
> I had the opportunity to discuss this patch at length with Heikki
> during pgConf.EU.
> The DESC heap TID sort order thing probably needs to go. I'll probably
> have to go fix the regression test failures that occur when ASC heap
> TID order
On 03.11.2018 5:00, Peter Geoghegan wrote:
The DESC heap TID sort order thing probably needs to go. I'll probably
have to go fix the regression test failures that occur when ASC heap
TID order is used. (Technically those failures are a pre-existing
problem, a problem that I mask by using DESC
On Fri, Nov 2, 2018 at 3:06 AM Andrey Lepikhov
wrote:
> Documentation is full and clear. All non-trivial logic is commented
> accurately.
Glad you think so.
I had the opportunity to discuss this patch at length with Heikki
during pgConf.EU. I don't want to speak on his behalf, but I will say
tha
I do the code review.
Now, it is first patch - v6-0001... dedicated to a logical duplicates
ordering.
Documentation is full and clear. All non-trivial logic is commented
accurately.
Patch applies cleanly on top of current master. Regression tests passed
and my "Retail Indextuple deletion" u
On Tue, Oct 23, 2018 at 11:35 AM Andrey Lepikhov
wrote:
> I have same problem with background heap & index cleaner (based on your
> patch). In this case the bottleneck is WAL-record which I need to write
> for each cleaned block and locks which are held during the WAL-record
> writing process.
Pa
On 19.10.2018 0:54, Peter Geoghegan wrote:
I would welcome any theories as to what could be the problem here. I'm
think that this is fixable, since the picture for the patch is very
positive, provided you only focus on bgwriter/checkpoint activity and
on-disk sizes. It seems likely that there
On Thu, Oct 18, 2018 at 1:44 PM Andres Freund wrote:
> I wonder if it'd make sense to hack up a patch that logs when evicting a
> buffer while already holding another lwlock. That shouldn't be too hard.
I tried this. It looks like we're calling FlushBuffer() with more than
a single LWLock held (n
On Thu, Oct 18, 2018 at 1:44 PM Andres Freund wrote:
> What kind of backend_flush_after values where you trying?
> backend_flush_after=0 obviously is the default, so I'm not clear on
> that. How large is the database here, and how high is shared_buffers
I *was* trying backend_flush_after=512kB,
Shared_buffers is 10gb iirc. The server has 32gb of memory. Yes, 'public'
is the patch case. Sorry for not mentioning it initially.
--
Peter Geoghegan
(Sent from my phone)
Hi,
On 2018-10-18 12:54:27 -0700, Peter Geoghegan wrote:
> I can show a nice improvement in latency on a slightly-rate-limited
> TPC-C workload when backend_flush_after=0 (something like a 40%
> reduction on average), but that doesn't hold up when oltpbench isn't
> rate-limited and/or has backend_
On Wed, Oct 3, 2018 at 4:39 PM Peter Geoghegan wrote:
> I did find a pretty clear regression, though only with writes to
> unique indexes. Attached is v6, which fixes the issue. More on that
> below.
I've been benchmarking my patch using oltpbench's TPC-C benchmark
these past few weeks, which has
On Fri, Sep 28, 2018 at 10:58 PM Andrey Lepikhov
wrote:
> I am reviewing this patch too. And join to Peter Eisentraut opinion
> about splitting the patch into a hierarchy of two or three patches:
> "functional" - tid stuff and "optimizational" - suffix truncation &
> splitting. My reasons are simp
28.09.2018 23:08, Peter Geoghegan wrote:
On Fri, Sep 28, 2018 at 7:50 AM Peter Eisentraut
wrote:
I think it might help this patch move along if it were split up a bit,
for example 1) suffix truncation, 2) tid stuff, 3) new split strategies.
That way, it would also be easier to test out each pie
On Fri, Sep 28, 2018 at 7:50 AM Peter Eisentraut
wrote:
> So. I don't know much about the btree code, so don't believe anything I
> say.
I think that showing up and reviewing this patch makes you somewhat of
an expert, by default. There just isn't enough expertise in this area.
> I was very int
On 19/09/2018 20:23, Peter Geoghegan wrote:
> Attached is v5,
So. I don't know much about the btree code, so don't believe anything I
say.
I was very interested in the bloat test case that you posted on
2018-07-09 and I tried to understand it more. The current method for
inserting a duplicate v
On Wed, Sep 19, 2018 at 11:23 AM Peter Geoghegan wrote:
> 3 modes
> ---
>
> My new approach is to teach _bt_findsplitloc() 3 distinct modes of
> operation: Regular/default mode, many duplicates mode, and single
> value mode.
I think that I'll have to add a fourth mode, since I came up with
an
On Wed, Sep 19, 2018 at 9:56 PM, Andrey Lepikhov
wrote:
> Note, that the interface of _bt_moveright() and _bt_binsrch() functions with
> combination of scankey, scantid and nextkey parameters is too semantic
> loaded.
> Everytime of code reading i spend time to remember, what this functions do
> e
I use the v5 version in quick vacuum strategy and in the heap&index
cleaner (see new patches at corresponding thread a little bit later). It
works fine and give quick vacuum 2-3% performance growup in comparison
with version v3 at my 24-core test server.
Note, that the interface of _bt_moveright
On Wed, Aug 1, 2018 at 9:48 PM, Andrey Lepikhov
wrote:
> I use v3 version of the patch for a Retail Indextuple Deletion and from time
> to time i catch regression test error (see attachment).
> As i see in regression.diff, the problem is instability order of DROP ...
> CASCADE deletions.
> Most fr
I use v3 version of the patch for a Retail Indextuple Deletion and from
time to time i catch regression test error (see attachment).
As i see in regression.diff, the problem is instability order of DROP
... CASCADE deletions.
Most frequently i get error on a test called 'updatable views'.
I chec
On Thu, Jun 14, 2018 at 11:44 AM, Peter Geoghegan wrote:
> I attach an unfinished prototype of suffix truncation, that also
> sometimes *adds* a new attribute in pivot tuples. It adds an extra
> heap TID from the leaf level when truncating away non-distinguishing
> attributes during a leaf page sp
On Tue, Jun 19, 2018 at 8:52 PM, Amit Kapila wrote:
> Both values will be present in the index, but the old value will be
> delete-marked. It is correct that we can't remove the value (index
> tuple) from the index until it is truly dead (not visible to anyone),
> but during a delete or index-upd
On Tue, Jun 19, 2018 at 11:13 PM, Peter Geoghegan wrote:
> On Tue, Jun 19, 2018 at 4:03 AM, Amit Kapila wrote:
>>> I imagine that retail index tuple deletion (the whole point of this
>>> project) would be run by a VACUUM-like process that kills tuples that
>>> are dead to everyone. Even with some
On Tue, Jun 19, 2018 at 4:03 AM, Amit Kapila wrote:
>> I imagine that retail index tuple deletion (the whole point of this
>> project) would be run by a VACUUM-like process that kills tuples that
>> are dead to everyone. Even with something like zheap, you cannot just
>> delete index tuples until
On Mon, Jun 18, 2018 at 10:33 PM, Peter Geoghegan wrote:
> On Mon, Jun 18, 2018 at 7:57 AM, Claudio Freire
> wrote:
>> Way back when I was dabbling in this kind of endeavor, my main idea to
>> counteract that, and possibly improve performance overall, was a
>> microvacuum kind of thing that woul
1 - 100 of 106 matches
Mail list logo
