Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Slow count(*) again...

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [HACKERS] Slow count(*) again...
Date: 2011-02-02 17:19:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
On Tue, Feb 1, 2011 at 6:44 PM, Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> wrote:
> On 2/1/2011 6:03 PM, Andrew Dunstan wrote:
>> Whether or not it's bad application design, it's ubiquitous, and we
>> should make it work as best we can, IMNSHO. This often generates
>> complaints about Postgres, and if we really plan for world domination
>> this needs to be part of it.
> There are many other things to fix first. One of them would be optimizer
> decisions when a temp table is involved.

It would be pretty hard to make autoanalyze work on such tables
without removing some of the performance benefits of having such
tables in the first place - namely, the local buffer manager.  But you
could ANALYZE them by hand.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-performance by date

Next:From: Greg SmithDate: 2011-02-02 17:24:26
Subject: Re: About pg_stat_activity
Previous:From: Maciek SakrejdaDate: 2011-02-02 17:15:01
Subject: Re: About pg_stat_activity

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2011-02-02 17:19:14
Previous:From: Tim BunceDate: 2011-02-02 17:16:00
Subject: Re: arrays as pl/perl input arguments [PATCH]

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group