Re: [HACKERS] MVCC overheads

Please see comment at the bottom of this post. On 08/07/16 10:48, Pete Stevenson wrote: Good info, thanks for the note. Agreed that it is difficult to pull things apart to isolate these features for offload — so actually running experiments with offload is not possible, as you point out (and

Re: [HACKERS] MVCC overheads

Peter Geoghegan wrote: > Has anyone ever done any kind of write-up of the "TED" design that was > discussed during FOSDEM (I hope I recall the name it was given > correctly)? Apparently that's something that's been discussed a few > times among senior community members, and I think it has

Re: [HACKERS] MVCC overheads

On Thu, Jul 7, 2016 at 11:45 AM, Pete Stevenson wrote: > Hi postgresql hackers - > > I would like to find some analysis (published work, blog posts) on the > overheads affiliated with the guarantees provided by MVCC isolation. More > specifically, assuming the current

Re: [HACKERS] MVCC overheads

On Fri, Jul 8, 2016 at 11:44 AM, Tom Lane wrote: >> Sure, but we could *also* do it separately, splitting VACUUMs tasks of >> tuple freezing, page compaction, and index entry removal each into >> separate tasks. > > Uh ... wouldn't that tend to make things worse? The knocks

Re: [HACKERS] MVCC overheads

On Thu, Jul 7, 2016 at 11:45 AM, Pete Stevenson wrote: > I would like to find some analysis (published work, blog posts) > on the overheads affiliated with the guarantees provided by MVCC > isolation. There are three levels of isolation implemented[1]; the incremental

Re: [HACKERS] MVCC overheads

Alvaro Herrera writes: > Tom Lane wrote: >> VACUUM in itself is an offloading optimization; the whole point of it >> is to do maintenance in a background process not foreground queries. > Well, if VACUUM worked so great, we wouldn't get so many trouble reports > with

Re: [HACKERS] MVCC overheads

Tom Lane wrote: > Alvaro Herrera writes: > > Pete Stevenson wrote: > >> Maybe I could figure out the lines of code that add versions into a > >> table and then those that collect old versions (they do get collected, > >> right?). Anyway, thought being I could profile

Re: [HACKERS] MVCC overheads

Alvaro Herrera writes: > Pete Stevenson wrote: >> Maybe I could figure out the lines of code that add versions into a >> table and then those that collect old versions (they do get collected, >> right?). Anyway, thought being I could profile while running TPC-C or >>

Re: [HACKERS] MVCC overheads

Pete Stevenson wrote: > Maybe I could figure out the lines of code that add versions into a > table and then those that collect old versions (they do get collected, > right?). Anyway, thought being I could profile while running TPC-C or > similar. I was hoping that someone might be able to jump

Re: [HACKERS] MVCC overheads

Good info, thanks for the note. Agreed that it is difficult to pull things apart to isolate these features for offload — so actually running experiments with offload is not possible, as you point out (and for other reasons). Maybe I could figure out the lines of code that add versions into a

Re: [HACKERS] MVCC overheads

On 8 July 2016 at 03:50, Pete Stevenson wrote: > Hi Simon - > > Thanks for the note. I think it's fair to say that I didn't provide enough > context, so let me try and elaborate on my question. > Please reply in-line in posts to make it easier to follow conversations

Re: [HACKERS] MVCC overheads

On 7 July 2016 at 20:50, Pete Stevenson wrote: > Hi Simon - > > Thanks for the note. I think it's fair to say that I didn't provide enough > context, so let me try and elaborate on my question. > > I agree, MVCC is a benefit. The research angle here is about enabling

Re: [HACKERS] MVCC overheads

Hi Simon - Thanks for the note. I think it's fair to say that I didn't provide enough context, so let me try and elaborate on my question. I agree, MVCC is a benefit. The research angle here is about enabling MVCC with hardware offload. Since I didn't explicitly mention it, the offload I refer

Re: [HACKERS] MVCC overheads

On 7 July 2016 at 17:45, Pete Stevenson wrote: > Hi postgresql hackers - > > I would like to find some analysis (published work, blog posts) on the > overheads affiliated with the guarantees provided by MVCC isolation. More > specifically, assuming the current workload

[HACKERS] MVCC overheads

Hi postgresql hackers - I would like to find some analysis (published work, blog posts) on the overheads affiliated with the guarantees provided by MVCC isolation. More specifically, assuming the current workload is CPU bound (as opposed to IO) what is the CPU overhead of generating the WAL,