On Thu, Nov 26, 2009 at 4:25 PM, Robert Haas <robertmh...@gmail.com> wrote: > Current version of patch is attached. I've revised it to use the > reloptions stuff, but I don't think it's committable as-is because it > currently thinks that extracting options from a pg_tablespace tuple is > a cheap operation, which was true in the non-reloptions-based > implementation but is less true now. At least, some benchmarking > needs to be done to figure out whether and to what extent this is an > issue.
Hmm. I'm not able to reliably detect a performance difference between unpatched CVS HEAD (er... git master branch) and same with spcoptions-v2.patch applied. I figured that if there were going to be an impact, it would be most likely to manifest itself in a query that touches lots and lots of tables but does very little actual work. So I used the attached script to create 200 empty tables, 100 in the default tablespace and 100 in tablespace "dork" (also known as, why I am working on this at 11 PM on Thanksgiving). Then I did: SELECT * FROM a1, a2, a3, ..., a100; ...and likewise for the bn. I tried this on an unpatched install and also with the patch applied, with and without options set on tablespace dork. I tried it a couple of times and the times were pretty consistent on any given run, but bounced around enough between runs that I can't say with any confidence that this patch makes any difference one way or the other. So it seems as if there is little reason to worry about caching, as Tom suspected, unless someone sees a flaw in my testing methodology. It might matter more in the future, if we have a larger number of tablespace options, but we could always add a cache then if need be. ...Robert
many-tables.sql
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
