Hi, Tim,
Tim Allen schrieb:
>> I don't know what "70 lac" means.
> One lac (also spelt "lakh") is one hundred thousand. And one crore is
> ten million. Indians count differently from the rest of the world :-).
Okay, so he talks about 7 million rows.
Thank you.
Markus
--
Markus Schaber wrote:
Does vacuum improves the performance of the database search.. As if now I
have a table who is having a records 70 lac and daily appx 10-15 thousand
rows get added. so please let me know which type of vacuum I should prefer.
I am accessing a data using java application which
Hi, Mahesh,
Mahesh Shinde wrote:
> Does vacuum improves the performance of the database search.. As if now I
> have a table who is having a records 70 lac and daily appx 10-15 thousand
> rows get added. so please let me know which type of vacuum I should prefer.
> I am accessing a data using jav
Hi, Christopher,
Christopher Browne wrote:
> Right. And part of the trouble is that you lose certainty that you
> have covered off transaction wraparound.
Yes. Vacuum (full) serve at least four purposes:
- TID wraparound prevention
- obsolete row removal
- table compaction
- giving space back
> Jim C. Nasby wrote:
>> On Tue, Feb 07, 2006 at 01:39:34PM +0100, Markus Schaber wrote:
>>
>>>Hi, Jim,
>>>
>>>Jim C. Nasby wrote:
>>>
>>>
What we really need is a replacement for vacuum_delay that takes
PostgreSQL generated IO activity into account...
>>>
>>>There are also other ideas whic
Jim C. Nasby wrote:
On Tue, Feb 07, 2006 at 01:39:34PM +0100, Markus Schaber wrote:
Hi, Jim,
Jim C. Nasby wrote:
What we really need is a replacement for vacuum_delay that takes
PostgreSQL generated IO activity into account...
There are also other ideas which can make vacuum less painfull
On Tue, Feb 07, 2006 at 01:39:34PM +0100, Markus Schaber wrote:
> Hi, Jim,
>
> Jim C. Nasby wrote:
>
> > What we really need is a replacement for vacuum_delay that takes
> > PostgreSQL generated IO activity into account...
>
> There are also other ideas which can make vacuum less painfull:
>
>
On Mon, Feb 06, 2006 at 11:05:45PM -0600, Jim C. Nasby wrote:
I don't really see the logic behind that. Problems caused by inadequate
vacuuming seem to be much more prevalent than problems caused by vacuum
impacting the system.
Agreed. If your tables are large enough that a vacuum matters, you
Hi, Jim,
Jim C. Nasby wrote:
> What we really need is a replacement for vacuum_delay that takes
> PostgreSQL generated IO activity into account...
There are also other ideas which can make vacuum less painfull:
- Use a "delete"-map (like the free space map) so vacuum can quickly
find the pages
On Mon, Feb 06, 2006 at 10:14:53PM -0800, Christopher Browne wrote:
> > On Wed, Feb 01, 2006 at 04:37:07PM -0500, Matthew T. O'Connor wrote:
> >> I think the default settings should be designed to minimize the impact
> >> autovacuum has on the system while preventing the system from ever
> >> get
> On Wed, Feb 01, 2006 at 04:37:07PM -0500, Matthew T. O'Connor wrote:
>> I think the default settings should be designed to minimize the impact
>> autovacuum has on the system while preventing the system from ever
>> getting wildly bloated (also protect xid wraparound, but that doesn't
>> have
On Wed, Feb 01, 2006 at 04:37:07PM -0500, Matthew T. O'Connor wrote:
> I think the default settings should be designed to minimize the impact
> autovacuum has on the system while preventing the system from ever
> getting wildly bloated (also protect xid wraparound, but that doesn't
> have anythi
matthew@zeut.net ("Matthew T. O'Connor") writes:
> I think the default settings should be designed to minimize the
> impact autovacuum has on the system while preventing the system from
> ever getting wildly bloated (also protect xid wraparound, but that
> doesn't have anything to do with the thres
On Feb 1, 2006, at 4:37 PM, Matthew T. O'Connor wrote:
As far I as I know, we are still looking for real world feedback.
8.1 is the first release to have the integrated autovacuum. The
thresholds in 8.1 are a good bit less conservative than the
thresholds in the contrib version. The con
Jim C. Nasby wrote:
Small tables are most likely to have either very few updates (ie: a
'lookup table') or very frequent updates (ie: a table implementing a
queue). In the former, even with vacuum_threshold = 0 vacuum will be a
very rare occurance. In the later case, a high threshold is likely to
As I recall, the idea behind vacuum_threshold was to prevent
too-frequent vacuuming of small tables. I'm beginning to question this
reasoning:
Small tables vacuum very, very quickly, so 'extra' vacuuming is very
unlikely to hurt system performance.
Small tables are most likely to have either very
16 matches
Mail list logo
