xml data type implications of no = - Mailing list pgsql-bugs

From Mark Kirkwood
Subject xml data type implications of no =
Date
Msg-id 4BFB5582.8000605@catalyst.net.nz
Whole thread Raw
Responses Re: xml data type implications of no =
List 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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5470: EXTRACT(epoch from ...) missing last digit
Next
From: Josh Williams
Date:
Subject: psql: SELECT INTO with FETCH_COUNT enabled