altering its execution..
--
Julius Tuskenis
Head of the programming department
UAB nSoft
mob. +37068233050
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
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
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
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
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
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
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:
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
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
;
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
=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
12 matches
Mail list logo