From: | Jens-Wolfhard Schicke <ml+pgsql-performance(at)asco(dot)de> |
---|---|
To: | |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: ORDER BY and LIMIT not propagated on inherited |
Date: | 2005-09-02 15:09:18 |
Message-ID: | 6A72374A62C8721E4E414937@[192.168.1.72] |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>>> The correct strategy IMHO would
>>> be applying the order by and limit for each child table (which results
>>> in an index scan, if possible), appending, then finally sorting a bunch
>>> of rows, and limiting again.
>>
>> This would be a win in some cases, and in many others a loss (ie, wasted
>> sort steps). The hard part is determining when to apply it.
>
> I don't actually know how many smaller separate sorts compare to a single
> big sort, but I guess the difference wouldn't be so big if the LIMIT is
> low. Add to this that you don't need to append the whole rowsets, but
> just smaller ones.
I think if you have a bunch of sorted thingies, you'd perform exactly one
merge step and be done, should be possible to do that in O(child_tables *
rows)...
Mit freundlichem Gruß
Jens Schicke
--
Jens Schicke j(dot)schicke(at)asco(dot)de
asco GmbH http://www.asco.de
Mittelweg 7 Tel 0531/3906-127
38106 Braunschweig Fax 0531/3906-400
From | Date | Subject | |
---|---|---|---|
Next Message | Patrick Hatcher | 2005-09-02 16:12:04 | Poor SQL performance |
Previous Message | Matteo Beccati | 2005-09-02 15:00:50 | Re: ORDER BY and LIMIT not propagated on inherited |