Re: [PERFORM] How to read query plan

Поиск
Список
Период
Сортировка
От Miroslav Šulc
Тема Re: [PERFORM] How to read query plan
Дата
Msg-id 4235AC01.600@startnet.cz
обсуждение исходный текст
Ответ на Re: [PERFORM] How to read query plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:

>=?windows-1250?Q?Miroslav_=8Aulc?= <miroslav.sulc@startnet.cz> writes:
>
>
>>As there are a lot of varchar(1) in the AdDevicesSites table, wouldn't
>>be helpful to change them to char(1)? Would it solve the variable-width
>>problem at least for some fields and speed the query up?
>>
>>
>
>No, because char(1) isn't physically fixed-width (consider multibyte
>encodings).  There's really no advantage to char(N) in Postgres.
>
>
I was aware of that :-(

>I don't know what you're doing with those fields, but if they are
>effectively booleans or small codes you might be able to convert them to
>bool or int fields.  There is also the "char" datatype (not to be
>confused with char(1)) which can hold single ASCII characters, but is
>nonstandard and a bit impoverished as to functionality.
>
>
The problem lies in migration from MySQL to PostgreSQL. In MySQL we
(badly) choose enum for yes/no switches (there's nothing like boolean
field type in MySQL as I know but we could use tinyint). It will be very
time consuming to rewrite all such enums and check the code whether it
works.

>However, I doubt this is worth pursuing.  One of the things I tested
>yesterday was a quick hack to organize the storage of intermediate join
>tuples with fixed-width fields first and non-fixed ones later.  It
>really didn't help much at all :-(.  I think the trouble with your
>example is that in the existing code, the really fast path applies only
>when the tuple contains no nulls --- and since you're doing all that
>left joining, there's frequently at least one null lurking.
>
>
Unfortunatelly I don't see any other way than LEFT JOINing in this case.

>            regards, tom lane
>
>
Miroslav

Вложения

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

Предыдущее
От: Miroslav Šulc
Дата:
Сообщение: Re: Avoiding tuple construction/deconstruction during joining
Следующее
От: Harald Fuchs
Дата:
Сообщение: Re: invalidating cached plans