Re: vacuum and row type

Teodor Sigaev <teodor@sigaev.ru>

From: Teodor Sigaev <teodor@sigaev.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-02T14:34:08Z
Lists: pgsql-hackers

Attachments

> 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@sigaev.ru
                                                    WWW: http://www.sigaev.ru/