On Thu, Apr 14, 2011 at 10:43:16AM -0400, Tom Lane wrote:
>
> I doubt that it's possible to make AllocSetAlloc radically cheaper.
> I think the more likely route to improvement there is going to be to
> find a way to do fewer pallocs. For instance, if we had more rigorous
> rules about which data structures are read-only to which code, we could
> probably get rid of a lot of just-in-case tree copying that happens in
> the parser and planner.
How much work would that be, and how would it be enforced in new
development?
> But at the same time, even if we could drive all palloc costs to
> zero, it would only make a 10% difference in this example. And this
> sort of fairly flat profile is what I see in most cases these days
> --- we've been playing performance whack-a-mole for long enough now
> that there isn't much low-hanging fruit left. For better or worse,
> the system design we've chosen just isn't amenable to minimal
> overhead for simple queries. I think a lot of this ultimately
> traces to the extensible, data-type-agnostic design philosophy. The
> fact that we don't know what an integer is until we look in pg_type,
> and don't know what an "=" operator does until we look up its
> properties, is great from a flexibility point of view; but this sort
> of query is where the costs become obvious.
Is it time to revisit that decision? Should we wait until, say, we no
longer claim to support 32-bit machines on the server side?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
