eplaced with subselects:
select (select count(*)... ) as societe_nbre_commandes
from societes ...
--
Regards,
Tomasz Myrta
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Hello
Does Postgres have ability to keep .dict and .affix files cached
globally for all client sessions?
Every time I connect to test server - it takes 3 seconds to load 4MB
dictionary when executing first FTS query.
--
Regards,
Tomasz Myrta
--
Sent via pgsql-performance mailing list
yourself - what do you have in "where" clause?
Example:
create index some_index on your_table(id_field) where not deleted;
Regards,
Tomasz Myrta
---(end of broadcast)---
TIP 8: explain analyze is your friend
is null
which doesn't make too much sense.
Check your queries. You probably have something like this:
select * from tablename where not deleted and xxx
Create your index to match xxx clause - if xxx is "some_id=13", then
create your index as:
create index on tablename(some_id)
primary key this way, right?
It looks much better now. I'm not sure about the second index. Probably
it will be useless, because you sort ALL records with deleteddtata is
null. Maybe the first index will be enough.
I'm not sure what to do with doubled index on a primary key
sing that index
But following query (notice there are less id-s in WHERE clause, but rest is
same)
select "REO_ID", "END_DATE" from "PRIORITY_STATISTICS" where "REO_ID" IN
('112851' ,'112859' ,'112871' ,'112883' ,&#
nd 60 Megs and goes through it, which it could
do in a fraction of the time.
Dror
Just like other aggregate functions, count(*) won't use indexes when
counting whole table.
Regards,
Tomasz Myrta
---(end of broadcast)---
TIP 1: subscribe and u
58) (actual
> time=135.87..1113.69 rows=9912 loops=1)
Well, it looks like a speed limit. I wouldn't expect better speed for
queries returning 1 rows.
Regards,
Tomasz Myrta
---(end of broadcast)---
TIP 8: explain analyze is your friend
on of the index.
Any idea?
thanks.
Adrián
where partido=99::int2 and partida=123;
Regards,
Tomasz Myrta
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
time function, which can be used for performance tests is timeofday().
You can read more about time functions in manual.
Regards,
Tomasz Myrta
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
#x27;select count(id)'
Yes, this is normal. Because of MVCC all rows must be checked and
Postgres doesn't cache count(*) like Mysql.
'select max(id)'
This is also normal, but try to change this query into:
select id from some_table order by id desc limit 1;
y is not using the index. Anybody knows what I'm doing wrong?
Over 25000 rows match your condition:
timestamp_in < to_timestamp( '20031201', 'MMDD' );
How many rows do you have in your table? It's possible, that seq scan is
just faster than us
rhead with managing
indexes.
The second (2 columns) index is useless - it's function is well done by
the first one (3 columns).
Regards,
Tomasz Myrta
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriat
Dnia 2004-02-02 19:30, Użytkownik scott.marlowe napisał:
Not entirely, since it only has to sort two columns, it will be smaller,
and will therefore be somewhat faster.
Can you say something more about it? Will it be enough faster to keep
them both? Did anyone make such tests?
Regards,
Tomasz
;IMMUTABLE"
You can read more about immutable, stable and volatile functions in
Postgresql documentation - chapter SQL Commands/CREATE FUNCTION.
Regards,
Tomasz Myrta
---(end of broadcast)---
TIP 6: Have you searched our list arc
15 matches
Mail list logo
