Re: [PERFORM] Slow query after upgrade from 8.2 to 8.4

AND CF.office = 18 AND DD.refid = CF.confid LIMIT 1; This is the query plan of the upper query. http://explain.depesz.com/s/ATN When we have 8.4.9 installed I will try the query and post the result. Best regards, Kaloyan Iliev Mark Kirkwood

Re: [PERFORM] Slow query after upgrade from 8.2 to 8.4

://explain.depesz.com/s/4zb I want this plan and this query but with the additional condition 'CF.office = 18'. How could I force the planner to use this plan and just filter the result. Best regards,  Kaloyan Iliev Tom Lane wrote: Kaloyan Iliev Iliev kalo...@digsys.bg writes: We

[PERFORM] Slow query after upgrade from 8.2 to 8.4

and set join_collapse_limit to 1 and see what will happen. Meanwhile any suggestions are welcome. Best regards and thanks in advance for the help. Kaloyan Iliev -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Question about LEFT JOIN and query plan

..5.13 rows=1 width=8) (never executed) Index Cond: (ac.ino = i.ino) Total runtime: 92.612 ms (34 rows) Kevin Grittner wrote: Kaloyan Iliev Iliev kalo...@digsys.bg wrote: I thing they should be access only if there are rows from the where. Why the left join executes first

Re: [PERFORM] Question about LEFT JOIN and query plan

, Kaloyan Iliev ==VERSION 8.2.15=== regbgrgr=# SELECT version(); version

Re: [PERFORM] Question about LEFT JOIN and query plan

=277.161..277.161 rows=59027 loops=1) - Seq Scan on request r (cost=0.00..1026.01 rows=59101 width=4) (actual time=0.075..131.951 rows=59027 loops=1) Total runtime: 2429.603 ms (26 rows) Kaloyan Iliev Iliev wrote: Hello again, I have another query which performance drops

[PERFORM] Query Optimization

ms Thanks in advance. Kaloyan Iliev -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Change query join order

Thanks You, I changed the random_page_cost to 2 and the query plan has changed and speeds up. I will check the other queries but I think I will leave it at this value. Thank you again. Kaloyan Iliev Robert Haas wrote: On Fri, Jan 8, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote

[PERFORM] Change query join order

on ms_commands_history. Now, if I red the explain correctly it first do the seq_scan on ms_commands_history the then the index scan on ms_data. Any Ideas? Thanks in advance. Kaloyan Iliev SELECT version(); version

Re: [PERFORM] Postgresql - Threshold value.

Hi, try using: tmp=# show all; and tmp=# show geqo_threshold; Regards, Kaloyan Iliev Ravindran G - TLS, Chennai. wrote: Hello, How to get Postgresql Threshold value ?. Any commands available ?. Regards, Ravi DISCLAIMER The contents of this e-mail and any attachment(s

[PERFORM] CURSOR OR OFFSET/LIMIT

between separe Browser request (and to give it time to live)? Or After all OFFSET and LIMIT? Thanks in advance. Kaloyan Iliev ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] Query not using index

time=0.053..0.059 rows=1 loops=1) Index Cond: ('193.68.0.10/32'::cidr = network) Total runtime: 0.167 ms (3 rows) Waiting for replies. Thanks to all in advance. Kaloyan Iliev ---(end of broadcast)--- TIP 4: Have you searched our list archives

[PERFORM] Query not using index

'::cidr = network) AND ((archived_at IS NULL) OR (archived_at '2005-11-17 00:00:00+02'::timestamp with time zone)) AND (valid_at '2005-12-01'::date) AND (confid 0)) Total runtime: 30.060 ms (3 rows) Thanks in advance to all. Kaloyan Iliev ---(end of broadcast

Re: [PERFORM] Query not using index

..0.059 rows=1 loops=1) Index Cond: ('193.68.0.10/32'::cidr = network) Total runtime: 0.167 ms (3 rows) Waiting for replies. Thanks to all in advance. Kaloyan Iliev ---(end of broadcast)--- TIP 4: Have you searched our list archives

Re: [PERFORM] How to read query plan

Hi, I have an idea about your problem. Will it be difficult not to change the entire code but only the queries? You can change type in the Postgres to bool. Then, when select data you can use a CASE..WHEN to return 'Y' or 'N' or even write a little function which accepts bool and returns 'Y'

Re: [PERFORM] 200 times slower then MSSQL??

Hi, First it will be good if you supply some EXPLAIN ANALYZE results from your query. Second, do you created the indexes which can be used with WHERE conditions. And Third AFAK MAX doesn't use index. If you only need max then you can try: ORDER BY DESC and LIMIT 1. But you can't use this

Re: [PERFORM] Performance problem from migrating between versions!

Hi, I try it and it doesn't resolve the problem:( So, now what? To leave it that way for this query or There must be permanent solution because if other queries behave like that? Kaloyan Iliev Tom Lane wrote: Kaloyan Iliev Iliev [EMAIL PROTECTED] writes: Will ANALYZE

[PERFORM] Performance problem from migrating between versions!

a view of the server configuration. Thanks in advance for all sugestions. Kaloyan Iliev SHOW ALL namesetting add_missing_fromon australian_timezonesoff authentication_timeout 60 check_function_bodies on checkpoint_segments 16 checkpoint_timeout 300 checkpoint_warning

Re: [PERFORM] Performance problem from migrating between versions!

for debugging the query planner. How it is used to debug the query planner? And why it lower the mem usage? Thank you in advance. Kaloyan Iliev Tom Lane wrote: Kaloyan Iliev Iliev [EMAIL PROTECTED] writes: I have the following problem. A week ago we've migrated from PGv7.2.3 to 7.4.6

Re: [PERFORM] Performance problem from migrating between versions!

turn it off for this query, so it can work. If I shouldn't, then what should I do? Will ANALYZE resove this? Kaloyan Iliev ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings