Tom Lane wrote:
=?windows-1250?Q?Miroslav_=8Aulc?= <[EMAIL PROTECTED]> 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 areThe 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
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.
Unfortunatelly I don't see any other way than LEFT JOINing in this case.
regards, tom laneMiroslav
adr;quoted-printable;quoted-printable:;;Vrchlick=C3=A9ho 161/5;Praha 5;;150 00;=C4=8Cesk=C3=A1 republika
tel;work:+420 257 225 602
tel;cell:+420 603 711 413
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])