Re: vacuum and row type
От | Teodor Sigaev |
---|---|
Тема | Re: vacuum and row type |
Дата | |
Msg-id | 4DE79F60.1060904@sigaev.ru обсуждение исходный текст |
Ответ на | Re: vacuum and row type (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: vacuum and row type
|
Список | 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@sigaev.ru WWW: http://www.sigaev.ru/
Вложения
В списке pgsql-hackers по дате отправления: