Re: [PERFORM] How to read query plan

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PERFORM] How to read query plan
Дата
Msg-id 13458.1110812581@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PERFORM] How to read query plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PERFORM] How to read query plan
Список pgsql-hackers
=?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 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.

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.

            regards, tom lane

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

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Raw size
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PERFORM] How to read query plan