On Mon, Apr 10, 2006 at 02:37:45PM +0200, Tomas Olaj wrote:
> On the marvelous Mon, 10 Apr 2006, Ruslan Zakirov wrote kindly to me ...
>
> http://archives.postgresql.org/pgsql-performance/2006-02/msg00089.php
>
> A proposal from the PostgreSQL developers how this SQL can be improved.
I believ
On the marvelous Mon, 10 Apr 2006, Ruslan Zakirov wrote kindly to me ...
This is one of the most problematic query in RT. I only can confirm
that the first plan (on Pg 7.x) is almost optimal one (there is still
way to optimize it with planner) and this is plan we wanted to achive
when were chang
On the marvelous Mon, 10 Apr 2006, Ruslan Zakirov wrote kindly to me ...
This is one of the most problematic query in RT. I only can confirm
that the first plan (on Pg 7.x) is almost optimal one (there is still
way to optimize it with planner) and this is plan we wanted to achive
when were chang
This is one of the most problematic query in RT. I only can confirm
that the first plan (on Pg 7.x) is almost optimal one (there is still
way to optimize it with planner) and this is plan we wanted to achive
when were changing this query in RT-3.4.5.
I hope Pg 8.1.4 would be available soon and we
Just translating a message from our DBA Rafael Martinez,
-->
We have a huge problem ahead of us which may delay our Service Guard
Cluster project.
Our last performance test with our new cluster and RT shows that we
have a SQL statement that 'planner" in Postgres 8.0.7 doesn't manage to
find
