On Mon, Sep 19, 2011 at 10:39 PM, Daniel Friesen
<lists(a)nadir-seen-fire.com> wrote:
On 11-09-19 06:39 PM, Anthony wrote:
On Mon, Sep 19, 2011 at 3:57 PM, Brion Vibber
<brion(a)pobox.com> wrote:
That's probably the simplest solution; adding
a new empty table will be very
quick. It may make it slower to use the field though, depending on what all
uses/exposes it.
Isn't adding a new column with all NULL values quick too?
Apparently in InnoDB a table ALTER requires an entire copy of the table
to do. In other words to do a table alter every box doing it needs to be
able to hold the entire Wikipedia revision table twice to add a new column.
Ah, okay. I remember that's what happened in MyISAM but I figured
they had that fixed in InnoDB.
On Mon, Sep 19, 2011 at 3:57 PM, Brion Vibber <brion(a)pobox.com> wrote:
During stub dump generation for instance this would
need to add a left outer
join on the other table, and add things to the dump output (and also needs
an update to the XML schema for the dump format). This would then need to be
preserved through subsequent dump passes as well.
Doesn't the stub dump generation computer have its own database? I
still don't see the point of putting all this extra work on the master
database in order to maintain a function-based index which is only
being used for dumps.
The dump generation computer should have its own database. For most
of the tables/dumps (probably all but the full-text ones), you could
even use sqlite and offer that as a download option for those who
aren't stuck in 1998.
On Tue, Sep 20, 2011 at 3:23 AM, Daniel Friesen
<lists(a)nadir-seen-fire.com> wrote:
On 11-09-19 11:43 PM, Domas Mituzas wrote:
> so, what are the use cases and how does one index for them? is it global hash check,
per page? etc
Calculating and storing checksums on every revision in the database is
way overkill for that.