type coerce problem with lztext
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | type coerce problem with lztext |
Дата | |
Msg-id | m12P2QD-0003kGC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответы |
Re: [HACKERS] type coerce problem with lztext
Re: [HACKERS] type coerce problem with lztext Re: [HACKERS] type coerce problem with lztext Re: [HACKERS] type coerce problem with lztext |
Список | pgsql-hackers |
Well, LZTEXT is there again, and pg_rewrite uses it for action and qual strings. This is what it tells: pgsql=# select rulename, length(ev_action), octet_length(ev_action) pgsql-# from pg_rewrite; rulename | length| octet_length ----------------+--------+-------------- _RETpg_user | 3043 | 855 _RETpg_rules | 3074 | 1139 _RETpg_views | 4261 | 1252 _RETpg_tables | 5187 | 1338 _RETpg_indexes | 3525 | 1122 (5 rows) Yes, the 3043 bytes long rule action string got stored in 855 bytes in pg_rewrite. That's 71.9% compression rateon this attempt! There are functions text(lztext) and lztext(text) too, but the system is unable to find an operator if one compares text=lztext in a query. IIRC, creating a function named as the target type and taking the source type is whatmade auto- type-conversion work - so what am I missing here? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: