Re: [PERFORM] How to read query plan - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PERFORM] How to read query plan
Date
Msg-id 13458.1110812581@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PERFORM] How to read query plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PERFORM] How to read query plan
List 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 by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Raw size
Next
From: Tom Lane
Date:
Subject: Re: [PERFORM] How to read query plan