Re: [HACKERS] Why frequently updated tables are an issue

2004-10-21 Thread Josh Berkus
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 problem

Re: Re: [HACKERS] Why frequently updated tables are an issue

2004-10-21 Thread simon
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

Re: [HACKERS] Why frequently updated tables are an issue

2004-10-20 Thread Manfred Spraul
[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

Re: [HACKERS] Why frequently updated tables are an issue

2004-10-20 Thread David Fetter
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 consider

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-18 Thread Bruce Momjian
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 define a

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-12 Thread Jan Wieck
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,

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-12 Thread Tom Lane
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. This

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-12 Thread Jan Wieck
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

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-12 Thread Tom Lane
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 lot. I

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-12 Thread Bruce Momjian
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 anything to do). The

[HACKERS] Why frequently updated tables are an issue

2004-06-10 Thread pgsql
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

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-10 Thread James Robinson
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

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-10 Thread Shridhar Daithankar
[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

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-10 Thread Glen Parker
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

Re: [HACKERS] Why frequently updated tables are an issue

2004-06-10 Thread Shridhar Daithankar
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