I'm thinking that this subject has some cross-overs with another topic
mentioned recently: improving VACUUM performance.
Just to recap: Frequently updated tables are a problem because they grow
significantly, with many useless row versions in there. The usual
solution is to run frequent VACUUMs o
Chris, Manfred, David, "Mohawk",
> > What about a dblink style interface to a non-MVCC SQL database? ÂI
> > think someone on this list mentioned that there are open source
> > in-memory SQL databases.
>
> Funny you should mention this. ÂI'm working on a generalized one that
> uses PL/PerlU at
The
On Wed, Oct 20, 2004 at 07:10:35PM +0200, Manfred Spraul wrote:
> [EMAIL PROTECTED] wrote a few months ago:
>
> >PostgreSQL's behavior on these cases is poor. I don't think anyone
> >who has tried to use PG for this sort of thing will disagree, and
> >yes it is getting better. Does anyone else c
[EMAIL PROTECTED] wrote a few months ago:
PostgreSQL's behavior on these cases is poor. I don't think anyone who has
tried to use PG for this sort of thing will disagree, and yes it is
getting better. Does anyone else consider this to be a problem? If so, I'm
open for suggestions on what can be don
Is there a TODO here? No one explained why frozen tuples are important.
---
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > On 6/12/2004 3:45 PM, Tom Lane wrote:
> >> I don't think it would help very much to def
Jan Wieck wrote:
> On 6/12/2004 3:45 PM, Tom Lane wrote:
>
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >> But a per relation bitmap that tells if a block is a) free of dead
> >> tuples and b) all remaining tuples in it are frozen could be used to let
> >> vacuum skip them (there can't be anythin
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 6/12/2004 3:45 PM, Tom Lane wrote:
>> I don't think it would help very much to define a bit like that --- I
>> can't believe that very many pages would contain only frozen tuples,
>> unless you were to adopt an aggressive policy of using VACUUM FREEZE
>> a
On 6/12/2004 3:45 PM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
But a per relation bitmap that tells if a block is a) free of dead
tuples and b) all remaining tuples in it are frozen could be used to let
vacuum skip them (there can't be anything to do). The bit would get
reset whenev
Jan Wieck <[EMAIL PROTECTED]> writes:
> But a per relation bitmap that tells if a block is a) free of dead
> tuples and b) all remaining tuples in it are frozen could be used to let
> vacuum skip them (there can't be anything to do). The bit would get
> reset whenever the block is marked dirty.
On 6/10/2004 10:37 AM, Shridhar Daithankar wrote:
[EMAIL PROTECTED] wrote:
The session table is a different issue, but has the same problems. You
have an active website, hundreds or thousands of hits a second, and you
want to manage sessions for this site. Sessions are created, updated many
times,
Glen Parker wrote:
It has been suggested in past to add such a visibility to index
tuple header so
that index and heaps can be cleaned out of order. In such a case
other backround
It seems to me that the benefit of this wouldn't be all that impressive
*when accessing the cache*, which is the proble
> It has been suggested in past to add such a visibility to index
> tuple header so
> that index and heaps can be cleaned out of order. In such a case
> other backround
It seems to me that the benefit of this wouldn't be all that impressive
*when accessing the cache*, which is the problem this dis
[EMAIL PROTECTED] wrote:
The session table is a different issue, but has the same problems. You
have an active website, hundreds or thousands of hits a second, and you
want to manage sessions for this site. Sessions are created, updated many
times, and deleted. Performance degrades steadily until a
On Jun 10, 2004, at 10:30 AM, [EMAIL PROTECTED] wrote:
Prior to lazy vacuum, this was impossible.
Do you know for sure that lazy vacuum and/or autovacuum does
not indeed solve / alleviate the symptoms of the general problem
of very high rate table updates?
Back to lurking!
James Robinson
Socia
OK, the problem I am having with whole discussion, on several fronts, is
the idea of performance. If performance and consistent behavior were not
*important* issues to a project, a summary table would work fine, and I
could just vacuum frequently.
Currently a client needs to vacuum two summary tab
15 matches
Mail list logo
