Re: Memory Accounting v11 - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Memory Accounting v11
Date
Msg-id 1436596133.4369.202.camel@jeff-desktop
Whole thread Raw
In response to Re: Memory Accounting v11  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Memory Accounting v11  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, 2015-07-09 at 14:41 +1200, David Rowley wrote:

> Are you going to implement this? or are you happy with the single
> level context tracking is the right thing?
> I'm going to mark the patch as waiting on author for now.

Attached a version of the patch that does multi-level tracking, v12. It
does this is a simpler way, just like an earlier version of the patch:
it simply traverses up the chain and adds to each parent in a
"total_allocated" field.

The idea you mentioned is a possible optimization of this idea, but it
only makes sense if I'm able to detect a difference between v11
(single-level) and v12 (multi-level). I tried Robert's test[1] again and
I didn't see a difference on my workstation (technically, v12 came out
the fastest, which means I'm just seeing noise anyway), so I can't
evaluate whether your idea will improve things.

After talking with a few people at PGCon, small noisy differences in CPU
timings can appear for almost any tweak to the code, and aren't
necessarily cause for major concern.

Regards,
    Jeff Davis

[1] pgbench -i -s 300, then do the following 3 times each for master,
v11, and v12, and take the median of logged traces:

start server; set trace_sort=on; reindex index pgbench_accounts_pkey;
stop server


Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: polymorphic types - enforce casting to most common type automatically
Next
From: Tomas Vondra
Date:
Subject: Re: PATCH: index-only scans with partial indexes