On Mon, Jul 12, 2010 at 4:33 PM, phb07 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
>> addin
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 co
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 the
-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
--
HOSTIN Damien - Equipe R&D
Tel:+33(0)4 63 05 95 40
Société Axège
23 rue Saint Simon
63000 Clermont Ferrand
www.axege.com
--- Begin Message ---
Robert Haas a écrit :
On Wed, Jul 7, 2010 at 10:39 AM, damien hostin wrote:
Hello again,
At last, I check the same query with the same data on
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 resistan
On Fri, Jul 9, 2010 at 6:13 AM, damien hostin 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 test case on t
Robert Haas a écrit :
On Wed, Jul 7, 2010 at 10:39 AM, damien hostin 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 q
On Wed, Jul 7, 2010 at 10:39 AM, damien hostin 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 query became quick
>
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 query
became quick (~200ms). Now 1classic sata disk computer is faster than
our
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
p
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 don't
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 runnin
13 matches
Mail list logo
