Re: Efficiency question: VARCHAR with empty string

Поиск
Список
Период
Сортировка
От Doug Fields
Тема Re: Efficiency question: VARCHAR with empty string
Дата
Msg-id 5.1.0.14.2.20020524150418.01ecdeb8@mail.pexicom.com
обсуждение исходный текст
Ответ на Re: Efficiency question: VARCHAR with empty string vs NULL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
At 02:54 PM 5/24/2002, you wrote:
>Doug Fields <dfields-pg-general@pexicom.com> writes:
> > Is there a performance difference with VARCHAR elements of value NULL and
> > zero-length string?
>
>These are not semantically equivalent (if you think they are, you've
>been using Oracle too long).  You will almost certainly regret it
>if you try recoding your app to make them equivalent.  An example:


Sorry, I haven't used Oracle in quite some time so I don't have any bad
Oracle-isms. :)

Thanks, Tom. Yes, I am aware of this already and my application largely
doesn't care (i.e. in the places it does it asks = '' as well as OR IS
NULL, but in most places it doesn't bother because it doesn't matter).

I'm merely trying to wring the last ounce of performance from the database,
especially given that most of these columns are rarely searched and
certainly not indexed.

>But to answer your question, NULLs might save a couple bytes if there
>are multiple NULLs per row.  I think that replacing a single empty
>varchar with a NULL would net out to no change (you lose the 4-byte
>varchar length word, but have to store a null-values bitmap instead),
>depending on alignment issues and how many columns there are in the
>table.

So, in essence, having a zero-length VARCHAR requires no additional page
loads (from the VARCHAR heap, if such a thing is used) and does not
increase the record size over having NULLs? My intent is to make this query
as fast as possible and require as few disk hits: SELECT * FROM table with
this many VARCHAR'd table.

Thanks,

Doug


В списке pgsql-general по дате отправления:

Предыдущее
От: Doug Fields
Дата:
Сообщение: Re: Altering existing table to be WITHOUT OIDs
Следующее
От: Doug Fields
Дата:
Сообщение: Re: Case Insensitive Data Type