Thread: vacuum row?
I originally suggested a methodology for preserving MVCC and everyone is confusing it as update "in place," this isnot what I intended. How about a form of vacuum that targets a particular row? Is this possible? Would if have to be by transaction?
Mark Woodward wrote: > I originally suggested a methodology for preserving MVCC and everyone is > confusing it as update "in place," this isnot what I intended. It doesn't make sense, but maybe vacuuming a page would. Naturally, it would need to wholly scan all the indexes to clean'em up, so it's probably not a good idea in general. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On 6/24/06, Mark Woodward <pgsql@mohawksoft.com> wrote: > I originally suggested a methodology for preserving MVCC and everyone is > confusing it as update "in place," this isnot what I intended. Actually, you should've presented your idea as performing MVCC the way Firebird does... the idea is basically the same. Doing some research never hurts... especially with this crowd. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Sun, 2006-06-25 at 05:29, Alvaro Herrera wrote: > Mark Woodward wrote: > > I originally suggested a methodology for preserving MVCC and everyone is > > confusing it as update "in place," this isnot what I intended. > > It doesn't make sense, but maybe vacuuming a page would. Naturally, it > would need to wholly scan all the indexes to clean'em up, so it's > probably not a good idea in general. But a version of vacuum which does normal index scans when vacuuming just a small percent of a huge table would make sense wouldn't it ? So you don't need to make full scans of the vacuumed indexes but look up the entries based on the vacuumed key. There were discussions about this I think, and the objection was that it might be that an index scan might miss index entries, in particular when badly behaved user defined functions are involved. Cheers, Csaba.
> On 6/24/06, Mark Woodward <pgsql@mohawksoft.com> wrote: >> I originally suggested a methodology for preserving MVCC and everyone is >> confusing it as update "in place," this isnot what I intended. > > Actually, you should've presented your idea as performing MVCC the way > Firebird does... the idea is basically the same. Doing some research > never hurts... especially with this crowd. Is it really nessisary make personal comments like this? Lets discuss "ideas" not personalities or people. The whole issue was how to address updates steadily degrading performance. I wanted to brainstorm the issue and find a solution. I tossed out a first guess at an algorithm to start the ball rolling. Was it perfect? No. Was it intended to be? no. It was intended to spark a discussion, get people, first to recognize the problem, and then to think about possible solutions. I find that this, while chaotic, usually finds the best solutions. There are a lot of good and smart people here who understand this process and see it for what it is. Unfortunately, some don't. It isn't about "research," per se, because it is assumed that we all know the various issues involved to some degree. It is about using the collective knowledge of the group and coming up with an answer. Over email, this can sometimes come off badly, and for that I appologize, but imagine, we were sitting at a table in "cambridge brewing company," and we had laptops and pitchers of beer and were discussing the problem. I'm at a stark disadvantage as I use PostgreSQL a lot, but don't have the luxury of being able to work on it in any real depth. I'd really love too.
On Mon, June 26, 2006 9:37 am, Mark Woodward wrote:
>> On 6/24/06, Mark Woodward <pgsql@mohawksoft.com> wrote:
>>
>>> I originally suggested a methodology for preserving MVCC and everyone
>>> is confusing it as update "in place," this isnot what I intended.
>>
>> Actually, you should've presented your idea as performing MVCC the way
>> Firebird does... the idea is basically the same. Doing some research
>> never hurts... especially with this crowd.
>
> Is it really nessisary make personal comments like this? Lets discuss
> "ideas" not personalities or people.
>
>
> The whole issue was how to address updates steadily degrading
> performance. I wanted to brainstorm the issue and find a solution. I
> tossed out a first guess at an algorithm to start the ball rolling.
>
> Was it perfect? No. Was it intended to be? no. It was intended to spark a
> discussion, get people, first to recognize the problem, and then to
> think about possible solutions.
>
> I find that this, while chaotic, usually finds the best solutions. There
> are a lot of good and smart people here who understand this process and see
> it for what it is. Unfortunately, some don't.
>
> It isn't about "research," per se, because it is assumed that we all know
> the various issues involved to some degree. It is about using the
> collective knowledge of the group and coming up with an answer.
Actually, it is. There are plenty of databases that don't need an
expensive separate process to clean out dead-space, so it would be wise to
see how those alternatives handle MVCC to see what this project can glean
from other's work- that is the point of open source.
Firebird, for example, has a half-dozen articles on how it handles MVCC
and dead tuples. In particular, it puts the "vacuum" burden on the
sessions and fires off a separate cleanup ("sweep") thread. After all,
what will know better than the transaction itself on what needs to be
cleaned up?
Linking goodness:
http://www.firebirdsql.org/doc/whitepapers/fb_vs_ibm_vs_oracle.htm
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_expert4
-M
On 6/26/06, Mark Woodward <pgsql@mohawksoft.com> wrote: > Is it really nessisary make personal comments like this? Lets discuss > "ideas" not personalities or people. Chill dude :) All I was saying is that if you look at past threads, this is a heavily discussed and near-religious topic. Doing some research before firing another shot across the bow wouldn't hurt. I do like the discussion though, it's good... I was just making an observation that it could've been brought up in a little more constructive way as there's a good amount of detail on Firebird's MVCC (not that it's perfect either), but it's a mature implementation sort of similar to the method you're discussing. Please don't take it personally... it surely wasn't meant that way. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Hello.. During a regular query , I got an werd error: billing=> select sum(duration)/60 from cdr__2006 where callstarttime<'2006-06-19 00:00:00'; ERROR: invalid page header in block 3527 of relation "cdr__2006_04_22"; Table cdr__2006_04_22 is a child of cdr__2006_04 , which is a child to cdr__2006. Can somebody explain this error ? What should I do ? Thanks Alex
On Mon, 2006-06-26 at 16:28 +0300, Alexandru Coseru wrote: > billing=> select sum(duration)/60 from cdr__2006 where > callstarttime<'2006-06-19 00:00:00'; > ERROR: invalid page header in block 3527 of relation "cdr__2006_04_22"; > > Table cdr__2006_04_22 is a child of cdr__2006_04 , which is a child to > cdr__2006. > > Can somebody explain this error ? What should I do ? Backup your database immediately. You may have corrupted data blocks. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com