Re: [PERFORM] How to read query plan

Tom Lane wrote:

>=?windows-1250?Q?Miroslav_=8Aulc?= <miroslav(dot)sulc(at)startnet(dot)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