Skip to content

oc_filecache: optimization structure > UNSIGNED! #46000

@mrAceT

Description

I am working on a project that "hooks" into Nextcloud. All is working quite well, but I just stumbled on something, something easily changed and does no harm and can only improve NextCloud:

There are quite a few 'bigint' field types in 'oc_filecache'.

As far as I know and can see all values are only positive, except size ( -1 for folder) and mtime could have an negative timestamp)
So making them UNSIGNED would be logical and (with fileid) would double the theoretical number of files NexCloud could handle!

Also:
Why is a number like storage a BIGINT? Wouldn't be a SMALLINT (unsigned: 65535) be enough? Or to be on the safe side a MEDIUMINT (unsigned: 16777215 is quite a ridiculous high number, wouldn't you say)?

And mimetype and mimepart, wouldn't be a SMALLINT (unsigned: 65535) be a more then safe maximum number?

And storage_mtime when set to "unsigned INT" the maximum value would be 4294967295 (February 7th 2106) would be more then fine for the next 80+ years!

This would improve the table structure, remove unwanted/impossible values, remove reserved space, thus make it smaler, so faster.

Easy change, easy benefit?

PS: as for mimetype (and others) also other tables can/must be altered (but filecache is one otf the big ones, so has the most to gain)

PS2: also the id in oc_mail_messages can be set to 'unsigned', doubling the amount that table can hold!

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions