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 <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
