| From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> | 
|---|---|
| To: | pgsql-bugs(at)postgresql(dot)org | 
| Subject: | xml data type implications of no = | 
| Date: | 2010-05-25 04:43:46 | 
| Message-ID: | 4BFB5582.8000605@catalyst.net.nz | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
Today I ran into some interesting consequences of the xml data type 
being without an "=" operator. One I thought I'd post here because it 
has a *possible* planner impact. I'm not sure it is actually a bug as 
such, but this seemed the best forum to post in initially:
test=# \d bug
       Table "public.bug"
  Column |  Type   | Modifiers
--------+---------+-----------
  id     | integer |
  val    | xml     |
test=# explain select val::text from bug;
                           QUERY PLAN
--------------------------------------------------------------
  Seq Scan on bug  (cost=0.00..58127.78 rows=1000278 width=32)
Note the width estimate. However a more realistic estimate for width is:
test=# select 8192/(reltuples/relpages) as width from pg_class where 
relname='bug';
       width
------------------
  394.130431739976
So we are going to massively underestimate the "size" of such a dataset. 
Now this appears to be a consequence of no "=" operator (std_typanalyze 
in analyze.c bails if there isn't one), so the planner has no idea about 
how wide 'val' actually is. I'm wondering if it is worth having at least 
an "=" operator to enable some minimal stats to be available for xml 
columns.
regards
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Hotchkiss | 2010-05-25 14:53:16 | BUG #5471: Postgres License Url is Misspelled | 
| Previous Message | Josh Williams | 2010-05-25 04:31:25 | psql: SELECT INTO with FETCH_COUNT enabled |