Re: How to check a table content efficiently? With LIMIT and OFFSET?

From: Stefan Keller <sfkeller(at)gmail(dot)com>
To: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Cc: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, pgsql-general List <pgsql-general(at)postgresql(dot)org>
Subject: Re: How to check a table content efficiently? With LIMIT and OFFSET?
Date: 2011-05-30 11:37:26
Message-ID: BANLkTikDxvuny5ZUzM20ci_b10v9QrxgOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Jaime

2011/5/30 Jaime Casanova <jaime(at)2ndquadrant(dot)com> wrote:
> On Sun, May 29, 2011 at 4:55 PM, Stefan Keller <sfkeller(at)gmail(dot)com> wrote:
>>
>>>> 2. There's an autovacuum background process which already does the
>>>> job, doesn't it?
>>>
>>> Yes, but in its own time. If you know there has been a batch of inserts/deletes you might as well run analyse immediately on that table.
>>
>> My table is a read-only table after all.
>> That's another reason why I'm reluctant using ANALYZE <table>.
>>
>
> sorry, i don't follow that... why do you think that a read-only table
> doesn't need an ANALYZE?

Thanks for joining the discussion.

I'm only reluctant to do an ANALYZE as part of a perdiodical (hourly)
"check table contents" function.

Such an ANALYZE command is already included in the perdiodical
(nightly) update script which mirrors OpenStreetMap data.

BTW: I've asked before for best parameters over at pgsql-performance
("How to configure a read-only database server?" 19. April 2011) and I
am still happy about any hint.

Yours, Stefan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sairam Krishnamurthy 2011-05-30 12:35:50
Previous Message salah jubeh 2011-05-30 10:51:49 time estimation for a test