Why does editing posts take longer than posting them?

[loinburger]

I've noticed far more "Your command has been ****ed up, please try again" errors when editing than when posting.

[Skanky Burns]

I generally get them when voting. ""

[Scouse Gits]

/me like smilies with ears "" *

and a crude timing test gives twice the time to edit than to post originally ...

[Lemmy]

Are you sure it uses a balanced b-tree? Looks like too much trouble.

yes, i searched at google, got directed to the mysql site (duh""), can't remember the url, or my exact search criteria, but i'm pretty sure...it said balanced b-tree

''

haha, your smilie has small ears ""

[Ecthy]

I created a monster ""

Guys, whenever you post a smiley with ears, remember who started it! And spell it right: Ec-the-lion ""

Anyway, I just asked if it was a balanced tree, but this morning I came to the conclusion that lists would be efficient enough. A list of forums, where each forum is a list of threads (easily sort-able and positions easily switch-able) where each thread is a list of posts. A big tree of posts would oly be useful if they were in some random order, so it's certainly not a balanced tree. The allocation with threads and forums would be too difficult.

BTW, the only lists that needs to bye really dynamic is a forum, because only threads exchange positions on the listing. But then, posts need to be removed as well.

And when I come and think about it, forums don't even need to be listed sort of dynamically, for they're in no real connection to each other. So they're just lists (forums, of threads) of lists (threads, of posts)

That's what I suppose. It seems more logical than one huge tree.

[Ecthy]

but that can't be it either... every time someone bumps a thread a list would have to be altered... given how long it takes to edit a post, posting as such would take lot longer... or?

[Grrr]

I almost posted a thread on this... Smilies with ears.

[Lemmy]

the way the threads are listed has nothing to do with the actual database structure, the way they are listed depends on the php-code, i odn't know MySql, but in sql there could be something like SORT BY lastpost.date, but you could also have something likwe SORT BY thread.name, then all threads would be shown by name, but the db structure would remain the same..

i wonder whast this looks like: ~~

[Urban Ranger]

I got to the mySQL site, can't be arsed to find the actual info though

[Lemmy]

i searched for "mysql structure tree" at google, it's the 2nd link ""

http://www.mysql.com/doc/I/n/InnoDB_physical_structure.html

[Ecthy]

so I was right about b-trees, but I'm not convinced by the system's efficiency

[Urban Ranger]

So the indices are stored in a b-tree. Still doesn't explain why edit takes longer, since theoretically append a new leaf node takes about the same amount of time as searching for an existing index.

Thanks Lemmy.

[Urban Ranger]

Did anybody notice this bit?

Page generated in 1.5208520 seconds (94.69% PHP - 5.31% MySQL) with 30 queries

More PHP operations might explain this.

[Lemmy]

hmm, let's test it...adding a new post...
/edit 1, this is what the bottom said:

Page generated in 0.2170900 seconds (79.53% PHP - 20.47% MySQL) with 30 queries
6.64 seconds

/edit 2, and this is the time for editing this post:

Page generated in 0.6924469 seconds (89.38% PHP - 10.62% MySQL) with 30 queries
6.16 seconds

[Lemmy]

10% more php when editing, generating also takes longer, but i don't think it's only because of that 10% more php, it must be a combination then, searching the tree, and php code