On Wed, Mar 9, 2011 at 1:11 PM, Bruce Momjian <br...@momjian.us> wrote: > Robert Haas wrote: >> On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> > Well, in principle we could allow them to work on both, just the same >> > way that (for instance) "+" is a standardized operator but works on more >> > than one datatype. ?But I agree that the prospect of two parallel types >> > with essentially duplicate functionality isn't pleasing at all. >> >> The real issue here is whether we want to store XML as text (as we do >> now) or as some predigested form which would make "output the whole >> thing" slower but speed up things like xpath lookups. We had the same >> issue with JSON, and due to the uncertainty about which way to go with >> it we ended up integrating nothing into core at all. It's really not >> clear that there is one way of doing this that is right for all use >> cases. If you are storing xml in an xml column just to get it >> validated, and doing no processing in the DB, then you'd probably >> prefer our current representation. If you want to build functional >> indexes on xpath expressions, and then run queries that extract data >> using other xpath expressions, you would probably prefer the other >> representation. > > Someone should measure how much overhead the indexing of xml values > might have. If it is minor, we might be OK with only an indexed xml > type.
I think the relevant thing to measure would be how fast the predigested representation speeds up the evaluation of xpath expressions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers