| From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: vacuum and row type |
| Date: | 2011-06-02 14:34:08 |
| Message-ID: | 4DE79F60.1060904@sigaev.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> isn't really specific to ANALYZE. I'm inclined to think that the most
> reasonable fix is to make get_sort_group_operators() and related
Hm, patch is in attach but it doesn't solve all problems. Initial bug is still
here for array of row type, but when I tried to change that with recursive call
get_sort_group_operators() as it done for row type then 'gmake check' fails
because lookup_rowtype_tupdesc fails to find anonymous composite type. As I can
see anonymous composite type are identified by (RECORD_OID, typmod) pair and
typmod aren't available here. So, my plan was to add typmod to
get_sort_group_operators() but I have no idea where is typmod value for element
type.
In runtime problems are solved by using HeapTupleHeaderGetTypMod() for record /
element of array.
With modified get_sort_group_operators() for arrays check actually fails for
query 'select * from search_graph order by path;' at file
src/test/regress/sql/with.sql. get_sort_group_operators() is called from
addTargetToSortList() and fails.
It seems to me that anonymous composite type could force us to teach
vacuum/analyze code to fallback to simpler analyze algorithm.
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
| Attachment | Content-Type | Size |
|---|---|---|
| get_sort_group_operators-0.1.gz | application/x-tar | 952 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marko Kreen | 2011-06-02 14:35:19 | Re: Please test peer (socket ident) auth on *BSD |
| Previous Message | Andrew Chernow | 2011-06-02 14:33:07 | Re: PQdeleteTuple function in libpq |