Hi!
I'm planning to move from mysql to postgresql as I believe the latter
performs better when it comes to complex queries. The mysql database
that I'm running is about 150 GB in size, with 300 million rows in the
largest table. We do quite a lot of statistical analysis on the data
which means
On 26-Jan-07, at 6:28 AM, John Parnefjord wrote:
Hi!
I'm planning to move from mysql to postgresql as I believe the latter
performs better when it comes to complex queries. The mysql database
that I'm running is about 150 GB in size, with 300 million rows in the
largest table. We do quite a
Hello !
Am Freitag 26 Januar 2007 12:28 schrieb John Parnefjord:
Hi!
I'm planning to move from mysql to postgresql as I believe the latter
performs better when it comes to complex queries. The mysql database
that I'm running is about 150 GB in size, with 300 million rows in the
largest
On Jan 25, 2007, at 10:33 AM, Ray Stell wrote:
On Thu, Jan 25, 2007 at 08:04:49AM -0800, Joshua D. Drake wrote:
It really depends on the system. Most of our systems run anywhere
from
10-25ms. I find that any more than that, Vacuum takes too long.
How do you measure the impact of setting
Hi,
I find various references in the list to this issue of queries
being too slow because the planner miscalculates things and
decides to go for a sequenctial scan when an index is available
and would lead to better performance.
Is this still an issue with the latest version? I'm doing some
Carlos Moreno skrev:
When I force it via set enable_seqscan to off, the index scan
takes about 0.1 msec (as reported by explain analyze), whereas
For the time being, I'm using an explicit enable_seqscan off
in the client code, before executing the select. But I wonder:
Is this still an
Carlos Moreno wrote:
Hi,
I find various references in the list to this issue of queries
being too slow because the planner miscalculates things and
decides to go for a sequenctial scan when an index is available
and would lead to better performance.
Is this still an issue with the latest
