Miroslav Šulc wrote:
> Tom Lane wrote:
>
>> ...
>> I think the reason this is popping to the top of the runtime is that the
>> joins are so wide (an average of ~85 columns in a join tuple according
>> to the numbers above). Because there are lots of variable-width columns
>> involved, most of the time the fast path for field access doesn't apply
>> and we end up going to nocachegetattr --- which itself is going to be
>> slow because it has to scan over so many columns. So the cost is
>> roughly O(N^2) in the number of columns.
>>
>>
> 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?
>
I'm guessing there really wouldn't be a difference. I think varchar()
and char() are stored the same way, just one always has space padding. I
believe they are both varlena types, so they are still "variable" length.
>> As a short-term hack, you might be able to improve matters if you can
>> reorder your LEFT JOINs to have the minimum number of columns
>> propagating up from the earlier join steps. In other words make the
>> later joins add more columns than the earlier, as much as you can.
>>
>>
> That will be hard as the main table which contains most of the fields
> is LEFT JOINed with the others. I'll look at it if I find some way to
> improve it.
One thing that you could try, is to select just the primary keys from
the main table, and then later on, join back to that table to get the
rest of the columns. It is a little bit hackish, but if it makes your
query faster, you might want to try it.
>
> I'm not sure whether I understand the process of performing the plan
> but I imagine that the data from AdDevicesSites are retrieved only
> once when they are loaded and maybe stored in memory. Are the columns
> stored in the order they are in the SQL command? If so, wouldn't it be
> useful to move all varchar fields at the end of the SELECT query? I'm
> just guessing because I don't know at all how a database server is
> implemented and what it really does.
>
I don't think they are stored in the order of the SELECT <> portion. I'm
guessing they are loaded and saved as you go. But that the order of the
LEFT JOIN at the end is probably important.
>> ..
>> regards, tom lane
>>
>>
> Miroslav
John
=:->