Re: effective SELECT from child tables

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: effective SELECT from child tables
Дата
Msg-id 433EB528.1000005@dunslane.net
обсуждение исходный текст
Ответ на Re: effective SELECT from child tables  ("Jim C. Nasby" <jnasby@pervasive.com>)
Список pgsql-hackers

Jim C. Nasby wrote:

>On Sat, Oct 01, 2005 at 02:13:09PM +0200, Martijn van Oosterhout wrote:
>  
>
>>On Fri, Sep 30, 2005 at 06:30:10PM -0500, Jim C. Nasby wrote:
>>    
>>
>>>On Wed, Sep 28, 2005 at 07:25:46PM +0100, Simon Riggs wrote:
>>>      
>>>
>>>>Include the Discriminator as a column in A and it will be inherited by
>>>>all A1, A2, A3. 
>>>>e.g. concrete_class    char(1) not null
>>>>        
>>>>
>>><snip>
>>>      
>>>
>>>>This will add 1 byte per row in your superclass... and requires no
>>>>        
>>>>
>>>I thought char was actually stored variable-length...? I know there's a
>>>type that actually acts like char does on most databases, but I can't
>>>remember what it is off-hand (it should be mentioned in docs 8.3...)
>>>      
>>>
>>IIRC, this is the difference between "char" and char(1). The latter is
>>variable length and can store any character per current encoding, hence
>>the variable length. "char" on the other hand is a one byte (presumably
>>ASCII) character. It's used mainly in the system catalogs...
>>    
>>
>
>According to the docs, char == char(1).
>  
>

The docs also say:

The type "char" (note the quotes) is different from char(1) in that it 
only uses one byte of storage. It is internally used in the system 
catalogs as a poor-man's enumeration type.

cheers

andrew



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCHES] Proposed patch for sequence-renaming problems
Следующее
От: Greg Stark
Дата:
Сообщение: Re: [PERFORM] A Better External Sort?