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

From: Conor Walsh <ctw(at)adverb(dot)ly>
To: jd(at)commandprompt(dot)com
Cc: Robert Haas <robertmhaas(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-04 02:45:09
Message-ID: AANLkTikR77m7ttGb5Y1y7HWa0Os95TQXj_+wgqa9Xkfm@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Thu, Feb 3, 2011 at 6:33 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> Well that already happens...

My understanding is that auto-analyze will fire only after my
transaction is completed, because it is a seperate daemon. If I do
like so:

BEGIN;
COPY ...;
-- Dangerously un-analyzed
SELECT complicated-stuff ...;
END;

Auto-analyze does not benefit me, or might not because it won't fire
often enough. I agree that analyze is very fast, and it often seems
to me like the cost/benefit ratio suggests making auto-analyze even
more aggressive.

Disclaimer/disclosure: I deal exclusively with very large data sets
these days, so analyzing all the time is almost a highly effective
worst-case amortization. I understand that constant analyze is not so
great in, say, an OLTP setting. But if the check is cheap, making
auto-analyze more integrated and less daemon-driven might be a net
win. I'm not sure.

-Conor

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Scott Marlowe 2011-02-04 02:59:46 Re: [HACKERS] Slow count(*) again...
Previous Message Itagaki Takahiro 2011-02-04 02:43:40 Re: exposing COPY API

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2011-02-04 02:59:46 Re: [HACKERS] Slow count(*) again...
Previous Message Joshua D. Drake 2011-02-04 02:33:30 Re: [HACKERS] Slow count(*) again...