Le 24 novembre 2011 18:20, MirrorX a écrit :
> hello to all,
>
> i would like your advice on the following matter. i have a table with 150
> million rows. there are some indexes on this table but the one that is
> really important is one that has 3 columns (a,b,c). one application
> constantly mak
On Thu, Nov 24, 2011 at 12:20 PM, MirrorX wrote:
> -32 cores,
> -not cpu bound (the cpu util was about 5% when i performed the tests)
A single query will only use a single CPU.
5% of 32 cores is 100% of 1.6 cores.
Are you sure that the 1 core doing the 1 postgresql query wasn't 100% utilized?
hello to all,
i would like your advice on the following matter. i have a table with 150
million rows. there are some indexes on this table but the one that is
really important is one that has 3 columns (a,b,c). one application
constantly makes queries and the query planner uses this index to narro
Maxim Boguk writes:
> Is here any reason why Postgresql calculates subqueries/storable procedures
> in select list before applying ORDER BY / LIMIT?
Well, that's the definition of ORDER BY --- it happens after computing
the select list, according to the SQL standard. We try to optimize this
in s
Is here any reason why Postgresql calculates subqueries/storable procedures
in select list before applying ORDER BY / LIMIT?
I talking about cases like:
SELECT *,
(some very slow subquery or slow storable stable/immutable procedure like
xml processing)
FROM
some_table
ORDER BY
some_field (unrelat
On 2011-11-21, Christiaan Willemsen wrote:
>We=
> are looking at beefing up our servers with SSD's. Some of you did so=
> me interesting tests with the Intel 320. So the idea came to make a RAID1=
> 0 with four 600GB models. I did however do some calcul=
> ations with the current database server
