From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Pre-alloc ListCell's optimization |
Date: | 2012-05-17 15:30:25 |
Message-ID: | 20120517153025.GZ1267@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Robert Haas (robertmhaas(at)gmail(dot)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 './configure' and pgbench -S -T 300, 3 runs each and then
averaged:
llist_opt: 9289 tps
HEAD: 9286 tps
I realize we see tons of palloc() calls happening but now I'm wondering
if they really contribute all that match time, overall. Also, I'm
wondering if all the benefit from removing the palloc()'s is being
sucked up by the regression in list_concat().
A few folks have mentioned just going whole-hog and doing all list
allocations in blocks of 8, which would actually allow us to go back to
an O(1) list_concat, though we wouldn't be able to free the 2nd list
passed to list_concat in that case, which may or may not be acceptable,
based on how necessary those couple pfree's we had previously are.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2012-05-17 16:26:24 | Re: Why is indexonlyscan so darned slow? |
Previous Message | Volker Grabsch | 2012-05-17 14:26:52 | Re: Missing optimization when filters are applied after window functions |