Kevin Grittner wrote:
> Kyotaro HORIGUCHI wrote:
>> I attached the your latest patch to this mail as
>> bt-nopin-v4.patch for now. Please check that there's no problem
>> in it.
>
> I checked out master, applied the patch and checked it against my
> latest code (merged with master), and it match
On Sat, Mar 14, 2015 at 4:07 PM, Simon Riggs wrote:
> -1 for a time based setting.
>
> After years of consideration, bloat is now controllable by altering
> the size of the undo tablespace.
>
Hm. Well, fwiw the situation is rather more complicated than that. You're
correct that you can create a
On 18 March 2015 at 03:01, Jim Nasby wrote:
> On 3/16/15 11:47 AM, Robert Haas wrote:
>>
>> I am sure there are more sophisticated things to be done here, but I
>> guess my feeling is that time is a good way to go here for a first cut
>> - lots of people have suggested it, and there's clearly a us
On 3/16/15 11:47 AM, Robert Haas wrote:
I am sure there are more sophisticated things to be done here, but I
guess my feeling is that time is a good way to go here for a first cut
- lots of people have suggested it, and there's clearly a use case for
it. If the setting turns out to be popular, w
On Mon, Mar 16, 2015 at 12:07 PM, Simon Riggs wrote:
>> What Simon actually proposed was by *bloat*; that is, if the overall
>> amount of bloat in the system exceeds some metric, start whacking old
>> queries in order to control it. The appeal of that is obvious,
>
> Agreed
>
>> but I
>> think it
On 16 March 2015 at 13:02, Robert Haas wrote:
> I'm not sure what the value of basing this on WAL volume is, and I
> think we should talk about that a bit more first. The value of doing
> this by rate of XID consumption is easy to understand: it's simple to
> implement. The value of doing this
On 16 March 2015 at 12:48, Kevin Grittner wrote:
> Simon Riggs wrote:
>> On 13 March 2015 at 15:41, Kevin Grittner wrote:
>>
>>> The feedback was generally fairly positive except for the fact that
>>> snapshot "age" (for purposes of being too old) was measured in
>>> transaction IDs assigned. T
Kyotaro HORIGUCHI wrote:
> Thank you for rewriting.
Thank *you* for pointing out where more work was needed in the
comments and README!
> I attached the your latest patch to this mail as
> bt-nopin-v4.patch for now. Please check that there's no problem
> in it.
I checked out master, applied th
On Mon, Mar 16, 2015 at 8:48 AM, Kevin Grittner wrote:
> Given that there seems to be disagreement on what is the more
> useful metric, do we want to consider allowing more than one? If
> so, would it be when *all* conditions are met or when *any*
> conditions are met?
Oh, gosh. Maybe we could
Simon Riggs wrote:
> On 13 March 2015 at 15:41, Kevin Grittner wrote:
>
>> The feedback was generally fairly positive except for the fact that
>> snapshot "age" (for purposes of being too old) was measured in
>> transaction IDs assigned. There seemed to be a pretty universal
>> feeling that this
Thank you for rewriting.
I was satisfied with the current patch (Head of btnopin on your
github repos). I have no further comment on the functions. Peter
might have a comment on the README description but I suppose I
can push this to the committers.
I attached the your latest patch to this mail a
On 13 March 2015 at 15:41, Kevin Grittner wrote:
> The feedback was generally fairly positive except for the fact that
> snapshot "age" (for purposes of being too old) was measured in
> transaction IDs assigned. There seemed to be a pretty universal
> feeling that this needed to be changed to a
On 13 March 2015 at 13:17, Robert Haas wrote:
> On Fri, Mar 13, 2015 at 8:52 AM, Simon Riggs wrote:
>> On 15 February 2015 at 00:19, Kevin Grittner wrote:
>>> What they wanted was what happened in the other database product --
>>> if a snapshot got sufficiently old that cleaning up the MVCC data
Robert Haas wrote:
> On Fri, Mar 13, 2015 at 8:52 AM, Simon Riggs wrote:
>> On 15 February 2015 at 00:19, Kevin Grittner wrote:
>>> What they wanted was what happened in the other database
>>> product -- if a snapshot got sufficiently old that cleaning up
>>> the MVCC data was a problem *and* th
Kyotaro HORIGUCHI wrote:
> At Thu, 12 Mar 2015 15:27:37 -0700, Peter Geoghegan wrote:
>> On Sat, Feb 14, 2015 at 4:19 PM, Kevin Grittner wrote:
>>> At some point we could consider building on this patch to
>>> recheck index conditions for heap access when a non-MVCC
>>> snapshot is used, check
On Fri, Mar 13, 2015 at 8:52 AM, Simon Riggs wrote:
> On 15 February 2015 at 00:19, Kevin Grittner wrote:
>> What they wanted was what happened in the other database product --
>> if a snapshot got sufficiently old that cleaning up the MVCC data
>> was a problem *and* the snapshot was used again
On 15 February 2015 at 00:19, Kevin Grittner wrote:
> What they wanted was what happened in the other database product --
> if a snapshot got sufficiently old that cleaning up the MVCC data
> was a problem *and* the snapshot was used again *and* it read a
> page which had been modified far enough
On 4 March 2015 at 03:16, Kevin Grittner wrote:
> How do people feel about the idea of me pushing this for 9.5 (after
> I clean up all the affected comments and README files)? I know
> this first appeared in the last CF, but the footprint is fairly
> small and the only user-visible behavior chan
Hello,
At Thu, 12 Mar 2015 15:27:37 -0700, Peter Geoghegan wrote in
> On Sat, Feb 14, 2015 at 4:19 PM, Kevin Grittner wrote:
> > At some point we could consider building on this patch to recheck
> > index conditions for heap access when a non-MVCC snapshot is used,
> > check the visibility map
On Sat, Feb 14, 2015 at 4:19 PM, Kevin Grittner wrote:
> At some point we could consider building on this patch to recheck
> index conditions for heap access when a non-MVCC snapshot is used,
> check the visibility map for referenced heap pages when the TIDs
> are read for an index-only scan, and/
Kevin Grittner wrote:
> Because these changes are just to a comment and a README file,
> I'm posting a patch-on-patch v3a (to be applied on top of v3).
Here is some additional comment work that I hope will make things
easier to understand for whoever next visits this code. There is
also a minor
Kevin Grittner wrote:
> Kyotaro HORIGUCHI wrote:
>> Would you mind rewriting the comment there like this?
>>
>> - /* The buffer is still pinned, but not locked. Lock it now. */
>> + /* I still hold the pin on the buffer, but not locked. Lock it now. */
>> Or would you mind renaming the macro a
Kyotaro HORIGUCHI wrote:
> I found no other problem including the performance issue in the
> patch attached to the last mail as far as I can understand. So
> I'll mark this as ready for commit after a few days with no
> objection after this comments is addressed.
Thanks for the reviews!
>> I do
Hello,
I found no other problem including the performance issue in the
patch attached to the last mail as far as I can understand. So
I'll mark this as ready for commit after a few days with no
objection after this comments is addressed.
> > - If (BTScanPosIsPinned(so->currPos)).
> >
> > As I me
Kevin Grittner wrote:
> It doesn't seem worth posting to the list for the small changes
> since the last version; I'll wait until I update the comments and
> README files. If you want review or test the latest, you can
> peek at:
>
> https://github.com/kgrittn/postgres/tree/btnopin
Here is v3,
Kyotaro HORIGUCHI wrote:
> The performance which your test shows looks great. The gain might
> comes from removing of buffer locking on _bt_next.
Yeah, I had been hoping that removing some buffer pins and locks
from the common path of scanning forward from one page to the next
might have some di
Hello,
> It looks like the remaining performance regression was indeed a
> result of code alignment. I found two "paranoia" assignments I had
> accidentally failed to put back with the rest of the mark/restore
> optimization; after that trivial change the patched version is
> ever-so-slightly fas
Kevin Grittner wrote:
> [need to check performance more]
It looks like the remaining performance regression was indeed a
result of code alignment. I found two "paranoia" assignments I had
accidentally failed to put back with the rest of the mark/restore
optimization; after that trivial change
Kyotaro HORIGUCHI wrote:
> Hello, I measured the performance of this patch considering
> markpos/restorepos. The loss seems to be up to about 10%
> unfortunately.
Thanks for the test case!
I took another look at this optimization, and found that it didn't
really depend on the pin (as I had firs
> "Kyotaro" == Kyotaro HORIGUCHI writes:
Kyotaro> Anyway I'm sorry but I have left my dev env and cannot have
Kyotaro> time till next week.
The point is moot; rather than try and explain it further I did the test
myself, and the performance penalty of disabling mark/restore is
substantial,
Hello.
Mmm... We might be focusing on a bit different things..
2015/02/27 17:27 "Andrew Gierth" > Kyotaro> I understand that you'd like
to see the net drag of
> Kyotaro> performance by the memcpy(), right?
>
> No.
>
> What I am suggesting is this: if mark/restore is a performance issue,
> then
> "Kyotaro" == Kyotaro HORIGUCHI writes:
Kyotaro> Just a reminder, but I am not the author of this patch:)
Yes, I understand that.
Kyotaro> Mmm? The patch bt-nopin-v1.patch seems not contain the change
Kyotaro> for ExecSupportMarkRestore and the very simple function remain
Kyotaro> look
Just a reminder, but I am not the author of this patch:)
At Fri, 27 Feb 2015 07:26:38 +, Andrew Gierth
wrote in <87zj7z6ckc@news-spur.riddles.org.uk>
> > "Kyotaro" == Kyotaro HORIGUCHI writes:
>
> >> You might want to try running the same test, but after patching
> >> ExecSupport
> "Kyotaro" == Kyotaro HORIGUCHI writes:
>> You might want to try running the same test, but after patching
>> ExecSupportsMarkRestore to return false for index scans. This will
>> cause the planner to insert a Materialize node to handle the
>> mark/restore.
Kyotaro> Mmm? The patch bt-n
Hi,
At Fri, 27 Feb 2015 05:56:18 +, Andrew Gierth
wrote in <874mq77vuu@news-spur.riddles.org.uk>
> > "Kyotaro" == Kyotaro HORIGUCHI writes:
>
> Kyotaro> ammarkpos/amrestrpos are called in merge joins. By the steps
> Kyotaro> shown below, I had 1M times of markpos and no restorepo
> "Kyotaro" == Kyotaro HORIGUCHI writes:
Kyotaro> ammarkpos/amrestrpos are called in merge joins. By the steps
Kyotaro> shown below, I had 1M times of markpos and no restorepos for
Kyotaro> 1M result rows, and had 500k times of markpos and the same
Kyotaro> number of times of restorepos f
Hello, I measured the performance of this patch considering
markpos/restorepos. The loss seems to be up to about 10%
unfortunately.
At Thu, 26 Feb 2015 17:49:23 + (UTC), Kevin Grittner
wrote in <440831854.629116.1424972963735.javamail.ya...@mail.yahoo.com>
> Heikki Linnakangas wrote:> On 02
Heikki Linnakangas wrote:> On 02/15/2015 02:19 AM,
Kevin Grittner wrote:
>> Interestingly, the btree README points out that using the old TID
>> with a new tuple poses no hazard for a scan using an MVCC snapshot,
>> because the new tuple would not be visible to a snapshot created
>> that long ago
On Mon, Feb 23, 2015 at 2:48 PM, Heikki Linnakangas
wrote:
>> Robert pointed out that the visibility information
>> for an index-only scan wasn't checked while the index page READ
>> lock was held, so those scans also still hold the pins.
>
> Why does an index-only scan need to hold the pin?
Supp
On 02/15/2015 02:19 AM, Kevin Grittner wrote:
Interestingly, the btree README points out that using the old TID
with a new tuple poses no hazard for a scan using an MVCC snapshot,
because the new tuple would not be visible to a snapshot created
that long ago.
The first question is: Do we really
We have a customer who was unable to migrate from a well-known
commercial database product to pg because they have a very large
software base that holds cursors open for very long periods of
time, preventing GlobalXmin values from advancing, leading to
bloat. They have a standard test that exercis
41 matches
Mail list logo
