On Mon, Jul 12, 2010 at 4:33 PM, phb07 ph...@apra.asso.fr wrote:
Dimitri a écrit :
It's probably one of the cases when having HINTS in PostgreSQL may be
very helpful..
SELECT /*+ enable_nestloop=off */ ... FROM ...
will just fix this query without impacting other queries and without
phb07 a écrit :
Dimitri a écrit :
It's probably one of the cases when having HINTS in PostgreSQL may be
very helpful..
SELECT /*+ enable_nestloop=off */ ... FROM ...
will just fix this query without impacting other queries and without
adding any additional instructions into the application
It's probably one of the cases when having HINTS in PostgreSQL may be
very helpful..
SELECT /*+ enable_nestloop=off */ ... FROM ...
will just fix this query without impacting other queries and without
adding any additional instructions into the application code..
So, why there is a such
--
HOSTIN Damien - Equipe RD
Tel:+33(0)4 63 05 95 40
Société Axège
23 rue Saint Simon
63000 Clermont Ferrand
www.axege.com
---BeginMessage---
Robert Haas a écrit :
On Wed, Jul 7, 2010 at 10:39 AM, damien hostin damien.hos...@axege.com wrote:
Hello again,
At last, I check the same query
-Ooops sorry for the spam-
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Dimitri a écrit :
It's probably one of the cases when having HINTS in PostgreSQL may be
very helpful..
SELECT /*+ enable_nestloop=off */ ... FROM ...
will just fix this query without impacting other queries and without
adding any additional instructions into the application code..
So, why
Robert Haas a écrit :
On Wed, Jul 7, 2010 at 10:39 AM, damien hostin damien.hos...@axege.com wrote:
Hello again,
At last, I check the same query with the same data on my desktop computer.
Just after loading the data, the queries were slow, I launch a vaccum
analyse which collect good stats
On Fri, Jul 9, 2010 at 6:13 AM, damien hostin damien.hos...@axege.com wrote:
Have you tried running ANALYZE on the production server?
You might also want to try ALTER TABLE ... SET STATISTICS to a large
value on some of the join columns involved in the query.
Hello,
Before comparing the
On Wed, Jul 7, 2010 at 10:39 AM, damien hostin damien.hos...@axege.com wrote:
Hello again,
At last, I check the same query with the same data on my desktop computer.
Just after loading the data, the queries were slow, I launch a vaccum
analyse which collect good stats on the main table, the
Hello,
Postgresql configuration was default. So I take a look at pgtune which
help me start a bit of tuning. I thought that the planner mistake could
come from the default low memory configuration. But after applying new
parameters, nothing has changed. The query is still low, the execution
Hello,
Before the week end I tried to change the index, but even with the
mono-column index on differents columns, the estimated number of rows
from dwhinv is 1.
Anyone have a suggestion, what can I check ?
thx
damien hostin a écrit :
Hello,
I try to make a query run quicker but I
Hello,
I try to make a query run quicker but I don't really know how to give
hints to the planner.
We are using postgresql 8.4.3 64bit on ubuntu 9.10 server. The hardware
is a 10 SAS drive (15k) on a single RAID 10 array with 8Go RAM.
Queries come from J2EE application (OLAP cube), but
12 matches
Mail list logo
