WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#39605 closed enhancement (duplicate)

Possible wp_options autoload field optimization

Reported by: danielkanchev Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.8
Component: Options, Meta APIs Keywords:
Focuses: Cc:

Description

I have a quick question related to the wp_options table and the autoload. Right now it is:

mysql> select distinct(autoload) from wp_options;
+----------+
| autoload |
+----------+
| no |
| yes |
+----------+
2 rows in set (0.00 sec)

If the only two possible options are ‘yes’ and ‘no’ then why is this not simple 0 or 1. The way it is defined right now we use 20 bytes per record only for the autoload:

| autoload | varchar(20) | NO | MUL | yes | |

I would say that in terms of performance and memory usage I think this is a good improvement. Any comments or there are other reasons for the autoload to be varchar.

Also if someone has a huge wp_options table and the autoload is boolean then the index will be much more effective.

Change History (3)

#1 @swissspidy
4 years ago

Previously discussed in #8924, #24044 and #14258.

#2 @rmccue
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #24044.

#3 @danielkanchev
4 years ago

@swissspidy and @rmccue thanks for the information and the links to the other tickets. I checked the other tickets and I have one question:

How many rows does the wp_options table need to have maximum to be considered "normal"?

In #14258 @pento wrote the following:

Even assuming a ludicrously massive wp_options table of 5000 rows

So I am wondering what is considered to be the maximum number of rows above which the wp_options table becomes bloated.

Note: See TracTickets for help on using tickets.