Re: [PERFORM] where clause + function, execution order

2011-11-11 Thread Julius Tuskenis
altering its execution.. -- Julius Tuskenis Head of the programming department UAB nSoft mob. +37068233050

Re: [PERFORM] Anti join miscalculates row number?

2011-10-27 Thread Julius Tuskenis
analyze on your database or at least the tables involved in the query ? -- Julius Tuskenis Head of the programming department UAB nSoft mob. +37068233050 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.or

Re: [PERFORM] how to use explain analyze

2011-10-26 Thread Julius Tuskenis
m queries like "delete from important_table" Thanks, Alan -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [PERFORM] generating a large XML document

2011-06-20 Thread Julius Tuskenis
quot; " -> Function Scan on fnk_access_control_tickets (cost=0.25..10.25 rows=1000 width=238) (actual time=495.703..503.999 rows=16292 loops=1)" "Total runtime: 1036.775 ms" Its over 10 times faster than using xmlagg. -- Julius Tuskenis Programavimo skyriaus vadova

Re: [PERFORM] generating a large XML document

2011-06-20 Thread Julius Tuskenis
Thank You, Samuel for the time it took to investigate the issue. I'll try to use buffer to see what the results are... I'll post results to the list if I succeed. -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050 -- Sent via pgsql-performance mailing l

Re: [PERFORM] generating a large XML document

2011-06-20 Thread Julius Tuskenis
r administrator. -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050 -- 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] generating a large XML document

2011-06-19 Thread Julius Tuskenis
Hello, I'm sorry to write again, but as I received no answer I wonder if there is a better mailing list to address concerning this question? Or is there nothing to be done about the speed of xmlagg ?. Please let me as no answer is the worst answer to get -- Julius Tuskenis Program

[PERFORM] generating a large XML document

2011-06-16 Thread Julius Tuskenis
Any notices, recommendations, advices are very welcome. I've also tried google'ing on XML creation in Postgresql, but found no warnings or even mentioning xmlagg could cause a headache. I have nowhere to turn for help now, so please advice... Not sure if that will help, but anyway:

Re: [PERFORM] unexpected stable function behavior

2011-03-15 Thread Julius Tuskenis
documentation (http://www.postgresql.org/docs/current/interactive/xfunc-volatility.html) would prevent misunderstandings in the future. -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050

Re: [PERFORM] unexpected stable function behavior

2011-03-15 Thread Julius Tuskenis
uting the query), so there is no way to determine the cost. That explains why not the optimal plan was chosen to my query. -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] unexpected stable function behavior

2011-03-14 Thread Julius Tuskenis
; I'm sorry, but I'm totally new to CTE. Would you please show me how should I use the stable function and where the parameters should be put to improve the behavior of the optimizer for my problem? Thank you in advance -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050

[PERFORM] unexpected stable function behavior

2011-03-10 Thread Julius Tuskenis
=258 width=4) (actual time=0.016..0.655 rows=619 loops=7)" "Index Cond: (ticket_has_ticket_price.thtp_price_id = ticket_price.price_id)" "Total runtime: 810.143 ms" So I am totally confused... It seems that selecting 4335 rows is a joke for Postgresql, bu