Re: [HACKERS] LONG

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] LONG
Дата
Msg-id 199912120001.TAA14030@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] LONG  (wieck@debis.com (Jan Wieck))
Ответы Re: [HACKERS] LONG  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>     Maybe  we  make  this  mechanism  so  general  that   it   is
>     automatically applied to ALL varsize attributes? We'll end up
>     with on big pg_long where 90+% of the databases content  will
>     be stored.
> 
>     But  as  soon as an attribute stored there is used in a WHERE
>     or is subject to be joined, you'll see why not (as said, this
>     type  will  NOT  be enabled for indexing). The operation will
>     probably fallback to a seq-scan on the main  table  and  then
>     the attribute must be fetched from pg_long with an index scan
>     on every single compare etc. - no, no, no.

A field value over 8k is not going to be something you join on,
restrict, or order by in most cases.  It is going to be some long
narrative or field that is just for output to the user, usually not used
to process the query.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] LONG
Следующее
От: wieck@debis.com (Jan Wieck)
Дата:
Сообщение: Jesus, what have I done (was: LONG)