Just looking at my database sizes. One DB, that contains 5 different
sites, is 454MB with 301 MB free space.
+--------------------+----------------------+------------------+
| Data Base Name | Data Base Size in MB | Free Space in MB |
+--------------------+----------------------+------------------+
| dropoid | 0.0288 | 0.0000 |
| habari | 434.3509 | 301.0794 |
| information_schema | 0.0078 | 0.0000 |
+--------------------+----------------------+------------------+
EEKK! after an optimize, I get that down to 131MB:
+--------------------+----------------------+------------------+
| Data Base Name | Data Base Size in MB | Free Space in MB |
+--------------------+----------------------+------------------+
| dropoid | 0.0288 | 0.0000 |
| habari | 131.0390 | 0.0000 |
| information_schema | 0.0078 | 0.0000 |
+--------------------+----------------------+------------------+
interestingly, this "extra" space seems to be mostly from comments, logs
and sessions. sessions, and somewhat logs, grow quickly. But little data
is used. Overtime it adds up though.
Investigating further, this 131MB is from old installs with massive log
size, one at 70MB the other at 42MB.
So, just my main up-to-date install:
SELECT table_schema "Data Base Name", SUM( data_length + index_length) /
1024 / 1024 "Data Base Size in MB" FROM information_schema.TABLES WHERE
table_name like 'habari__%' GROUP BY table_schema;
+----------------+----------------------+
| Data Base Name | Data Base Size in MB |
+----------------+----------------------+
| habari | 0.90812397 |
+----------------+----------------------+
barely 1 MB for a site with: "Matt Read, Weblog has been active for 9
years, 3 weeks and 5 days. The 2 authors have published 211 posts with
1119 comments and 74 tags"
My posts table is even smaller:
| habari__posts | 0.22566223 |
While someone else's on my server, let's call him Mick:
| habari__posts | 1.41213608 |
When I think about writing a post, especially a long one. I click save
many times. let's say I click save 10 times on each post. As it stands,
if my quick glance at the code is right, this would essentially make
revisions take up, roughly, 10 times my posts table's current size; 2MB.
And Mick's would be 14MB.
This is not unreasonable. Although garbage collection may be in order.
Now I'll talk crazy. Remember that update/date feed position thing and
minor edits? This could come into play here too? /me runs away from that
one.
On 31/01/2013 11:36 PM, Owen Winkler wrote:
I really like the idea of providing all of the underlying tools that
integrators might need to build sites on top of Habari. Revisions seem
to me like a missing component, as did taxonomy, which allowed us to
build pluggable features on top, like menus. There is currently no
underlying, unifying data structure that could be used for revision or
workflow features, so I think this is a good and welcome addition.
As to the greater point of addressing user concerns, I agree. I think
it's important to have a useful, competitive tool that also provides a
robust framework on which to build. I'd like to discuss other features
related to this, specifically WYSIWYG and the recent auto-install ideas
from IRC, but under different cover.
The only argument I've heard against revisions so far that seems valid
is that it may increase default storage requirements for users with many
revisions. This may be true. I could be persuaded to consider storing
revisions being disabled by default, but the argument against seems more
about the code being "lean and mean" than storage requirements. I don't
think this feature causes feature/code bloat; rather, I think it's an
expected essential capability for baseline blogging today.
Owen
--
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/habari-dev
---
You received this message because you are subscribed to the Google
Groups "habari-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/habari-dev
---
You received this message because you are subscribed to the Google Groups "habari-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
