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
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 |
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... |