xml data type implications of no =
От | Mark Kirkwood |
---|---|
Тема | xml data type implications of no = |
Дата | |
Msg-id | 4BFB5582.8000605@catalyst.net.nz обсуждение исходный текст |
Ответы |
Re: xml data type implications of no =
|
Список | 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 по дате отправления: