Excerpts from Stephen Frost's message of mié ago 29 21:46:06 -0400 2012:
> Based on the test runs that I did using Josh's box (thanks!), the
> performance with the pre-allocation patch and an pre-alloc of 8 ends up
> being about a wash. Allocating less (4) or more (16) actually makes
> things wor
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, May 18, 2012 at 06:19:52PM -0400, Stephen Frost wrote:
> > Dropping it to 4 improved performance a bit: 9476 tps.
> >
> > Going to keep playing around and see where this goes.
>
> Any status on this?
Based on the test runs that I did us
On Fri, May 18, 2012 at 06:19:52PM -0400, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > > llist_opt: 9289 tps
> > > HEAD: 9286 tps
> >
> > llist_opt: 9407 tps
> >
> > Which gives us ~1.3% improvment.
>
> Trying out some different options- going with 32 pre-allocated
* Stephen Frost (sfr...@snowman.net) wrote:
> > llist_opt: 9289 tps
> > HEAD: 9286 tps
>
> llist_opt: 9407 tps
>
> Which gives us ~1.3% improvment.
Trying out some different options- going with 32 pre-allocated
ListCell's actually reduced performance, according to these tests.
Dropping it
* Stephen Frost (sfr...@snowman.net) wrote:
> Alright, so I've done some pgbench's using all default configs with just
> a straight up './configure' and pgbench -S -T 300, 3 runs each and then
> averaged:
>
> llist_opt: 9289 tps
> HEAD: 9286 tps
Ok, apparently part of the issue with the prev
* Robert Haas (robertmh...@gmail.com) wrote:
> So I guess the first question here is - does it improve performance?
>
> Because if it does, then it's worth pursuing ... if not, that's the
> first thing to fix.
Alright, so I've done some pgbench's using all default configs with just
a straight up
All,
Here's an updated version of the patch which cleans up a couple of the
previous issues, including addressing some of the free'ing issues.
Looking forward to comments.
Thanks,
Stephen
diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
in
* Stephen Frost (sfr...@snowman.net) wrote:
> The two cases in clauses.c are pretty specific and documented:
>
> List *subargs = list_copy(((BoolExpr *) arg)->args);
>
> /* overly tense code to avoid leaking unused list header */
> if (!unprocessed_args)
> unprocessed_
Tom,
* Stephen Frost (sfr...@snowman.net) wrote:
> Second, there are a couple of bugs (or at least, I'll characterize
> them that way) where we're pfree'ing a list which has been passed to
> list_concat(). That's not strictly legal as either argument passed to
> list_concat() could be ret
* Stephen Frost (sfr...@snowman.net) wrote:
> So, when it comes to palloc() reduction, this patch would eliminate 99%
> of palloc's due to lists. For the regression tests, we're talking about
> reducing 893,206 palloc calls to only 1.
Apologies, that wasn't quite right- it'd reduce it to 1 palloc
* Stephen Frost (sfr...@snowman.net) wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > ISTM the first thing we'd need to have before
> > we could think about this rationally is some measurements about the
> > frequencies of different List lengths in a typical workload.
>
> I agree, that'd be a g
Greg,
* Greg Stark (gsst...@mit.edu) wrote:
> On Thu, May 26, 2011 at 8:52 PM, Stephen Frost wrote:
> > list_concat() does explicitly say that cells will
> > be shared afterwards and that you can't pfree() either list (note that
> > there's actually a couple cases currently that I discovered whi
* Greg Stark (gsst...@mit.edu) wrote:
> On Thu, May 26, 2011 at 11:57 AM, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > While I agree that there is some bloat that'll happen with this
> > approach, we could reduce it by just having a 4-entry cache instead of
> > an 8-entry ca
On Thu, May 26, 2011 at 8:52 PM, Stephen Frost wrote:
> list_concat() does explicitly say that cells will
> be shared afterwards and that you can't pfree() either list (note that
> there's actually a couple cases currently that I discovered which were
> also addressed in the original patch where
* Greg Stark (gsst...@mit.edu) wrote:
> On Thu, May 26, 2011 at 11:57 AM, Stephen Frost wrote:
> > Handling the 1-entry case would likely be pretty
> > straight-forward, but you need book-keeping as soon as you go to two,
> > and all that book-keeping feels like overkill for just a 2-entry cache
>
On Thu, May 26, 2011 at 11:57 AM, Stephen Frost wrote:
> Handling the 1-entry case would likely be pretty
> straight-forward, but you need book-keeping as soon as you go to two,
> and all that book-keeping feels like overkill for just a 2-entry cache
> to me.
Incidentally what if I call nconc and
On Thu, May 26, 2011 at 11:57 AM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'm worried that this type of approach would
>> bloat the storage required in those cases to a degree that would make
>> the patch unattractive.
>
> While I agree that there is some bloat that'll hap
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm worried that this type of approach would
> bloat the storage required in those cases to a degree that would make
> the patch unattractive.
While I agree that there is some bloat that'll happen with this
approach, we could reduce it by just having a 4-
On Tue, May 24, 2011 at 10:56 PM, Stephen Frost wrote:
> Someone (*cough*Haas*cough) made a claim over beers at PGCon that it
> would be very difficult to come up with a way to pre-allocate List
> entries and maintain the current List API. I'll admit that it wasn't
> quite as trivial as I had
Stephen Frost writes:
> Basically, I added a ListCell array into the List structure and then
> added a bitmap to keep track of which positions in the array were
> filled.
Hm. I've gotten the impression from previous testing that there are an
awful lot of extremely short lists (1 or 2 elements) r
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> I think what this patch is mainly missing is a description of how the
> new allocation is supposed to work, so that we can discuss the details
> without having to reverse-engineer them from the code.
Sure, sorry I didn't include something more
Excerpts from Stephen Frost's message of mar may 24 22:56:21 -0400 2011:
> Greetings,
>
> Someone (*cough*Haas*cough) made a claim over beers at PGCon that it
> would be very difficult to come up with a way to pre-allocate List
> entries and maintain the current List API. I'll admit that it
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> Excerpts from Stephen Frost's message of mar may 24 22:56:21 -0400 2011:
>
> > A couple of notes regarding the patch:
> >
> > First, it uses ffs(), which might not be fully portable.. We could
> > certainly implement the same thing in
Excerpts from Stephen Frost's message of mar may 24 22:56:21 -0400 2011:
> A couple of notes regarding the patch:
>
> First, it uses ffs(), which might not be fully portable.. We could
> certainly implement the same thing in userspace and use ffs() when
> it's available.
Err, see RIGHTM
* Stephen Frost (sfr...@snowman.net) wrote:
> Finally, sorry it's kind of a fugly patch, it's just a proof of
> concept and I'd be happy to clean it up if others feel it's worthwhile
> and a reasonable approach, but I really need to get it out there and
> take a break from it (I've been a b
25 matches
Mail list logo
