SEO

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?

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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.



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> 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.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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/white..._vs_oracle.htm
http://www.ibphoenix.com/main.nfs?a=...ge=ibp_expert4

-M



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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/

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster