Re: FUNCTIONs and CASTs
От | Dean Gibson (DB Administrator) |
---|---|
Тема | Re: FUNCTIONs and CASTs |
Дата | |
Msg-id | 47B61A26.4060806@ultimeth.com обсуждение исходный текст |
Ответ на | Re: FUNCTIONs and CASTs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: FUNCTIONs and CASTs
|
Список | pgsql-sql |
On 2008-02-15 14:32, Tom Lane wrote: <blockquote cite="mid:655.1203114745@sss.pgh.pa.us" type="cite"><pre wrap="">"DeanGibson (DB Administrator)" <a class="moz-txt-link-rfc2396E" href="mailto:postgresql@ultimeth.com"><postgresql@ultimeth.com></a>writes: </pre><blockquote type="cite"><pre wrap="">Again,you are not understanding my point. My point was that specifying tablename.columnname%TYPE notation doesn't help with the performance problem; I have to explicitly cast the parameter in the body of the function. </pre></blockquote><pre wrap=""> The reason for the lack of communication is that no one else believes that premise. Casting a value to the same type it already has is demonstrably a no-op. </pre></blockquote> Casing a TEXT item to a CHAR( 9 ) item isn't a no-op. I've seen this before in"EXPLAIN ..." output, where a search on an indexed column will be sequential because the planner treats the search valueas TEXT rather than CHAR( 9 ).<br /><br /> Are you saying that no one believes there is a performance difference? Amazing...<br /><br /> Tom, I've privately eMailed you access instructions to one of my DB servers, so you can see for yourself.<br/><br /><pre class="moz-signature" cols="72">-- Mail to my list address MUST be sent via the mailing list. All other mail to my list address will bounce.</pre>
В списке pgsql-sql по дате отправления: