On Wed, Nov 12, 2008 at 8:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> - - <[EMAIL PROTECTED]> writes:
>> One of my tables has 660,000 records and doing a SELECT * from that table
>> (without any joins or sorts) takes 72 seconds. Ordering the table based on 3
>> columns almost doubles that time t
Hello !
Sorry for the subject, I didn't found a better one ! :-/
I'm having a problem with this query (below) that takes betweend 14 and
15 seconds to run, which is too long for the end-user.
I've done a EXPLAIN ANALYZE (below below) but I'm having difficulties to
see which part of that quer
On Wed, Nov 12, 2008 at 11:27 AM, - - <[EMAIL PROTECTED]> wrote:
> I've been searching for performance metrics and tweaks for a few weeks now.
> I'm trying to determine if the length of time to process my queries is
> accurate or not and I'm having a difficult time determining that. I know
> postgr
Bruno Baguette <[EMAIL PROTECTED]> writes:
> I'm having a problem with this query (below) that takes betweend 14 and
> 15 seconds to run, which is too long for the end-user.
> I've done a EXPLAIN ANALYZE (below below) but I'm having difficulties to
> see which part of that query is taking so many
Bruno Baguette napisal 13.11.2008 12:02:
Hello !
Sorry for the subject, I didn't found a better one ! :-/
I'm having a problem with this query (below) that takes betweend 14 and
15 seconds to run, which is too long for the end-user.
I've done a EXPLAIN ANALYZE (below below) but I'm having di
On Thu, 13 Nov 2008, Bruno Baguette wrote:
I'm having a problem with this query (below) that takes between 14 and 15
seconds to run, which is too long for the end-user.
I've done a EXPLAIN ANALYZE (below below) but I'm having difficulties to see
which part of that query is taking so many times
Le 13/11/08 14:31, Tom Lane a écrit :
It's the repeatedly executed EXISTS subplan that's hurting you:
SubPlan
-> Nested Loop (cost=35.56..378.16
rows=2 width=0) (actual time=16.511..16.511 rows=0 loops=818)
16.511 * 818 = 13505.998,
Could you please try this one:
SELECT pk_societe_id,
denomination_commerciale,
denomination_sociale,
numero_client,
COALESCE(stats_commandes.nombre, 0) AS societe_nbre_commandes,
COALESCE(stats_adresses_livraison.nombre, 0) AS
societe_adresses_livraison_quantite,
Bruno Baguette <[EMAIL PROTECTED]> writes:
> Le 13/11/08 14:31, Tom Lane a écrit :
>> 16.511 * 818 = 13505.998, so this is all but about 100 msec of the
>> runtime. Can't tell if there's any easy way to improve it. In
>> pre-8.4 releases trying to convert the EXISTS into an IN might help.
> Can
Le 13/11/08 14:28, Matthew Wakeling a écrit :
On Thu, 13 Nov 2008, Bruno Baguette wrote:
I'm having a problem with this query (below) that takes between 14 and
15 seconds to run, which is too long for the end-user.
I've done a EXPLAIN ANALYZE (below below) but I'm having difficulties
to see w
Le 13/11/08 15:29, Vladimir Sitnikov a écrit :
Could you please try this one:
Hello Vladimir !
Thanks for your suggest ! I've changed a small typo in your SQL query
suggestion (extra comma in the second LEFT JOIN).
Your suggest is fast also (137 ms), but it returns less rows than mine
(39 ro
ok, I have an application that I am trying to speed up. Its a reporting
application that makes heavy use of the crosstab function.
Here is some of the setup / configuration details:
Postgres 8.3.3
RedHat Enterprise 5.2 (2.6.18 kernel)
sun x4600, 8 dual core opteron 8218 processors, 32BG, StorageT
On Thu, Nov 13, 2008 at 1:42 PM, Jeremiah Elliott <[EMAIL PROTECTED]> wrote:
> ok, I have an application that I am trying to speed up. Its a reporting
> application that makes heavy use of the crosstab function.
>
> Here is some of the setup / configuration details:
> Postgres 8.3.3
> RedHat Enterp
Jeremiah Elliott wrote:
ok, I have an application that I am trying to speed up. Its a reporting
application that makes heavy use of the crosstab function.
here is an example query
The crostab function is taking between 5 and 15 seconds to return.
Please run the two embedded queries ind
14 matches
Mail list logo
