Change Details

Epic at T145912 @bd808 had some solid ideas about how we could represent each IP (v4 or v6) as a unique value in an indexed column, which should make simple queries fairly fast. Let's hash out the details and come up with a plan. Currently the only useful index for this is a non-unique index on (rev_user_text, rev_timestamp) in the revision table. Let's answer the following questions: 1. What CIDR ranges would be useful to support searches for (both for IPv4 and IPv6)? This may require asking some administrators. 1. With the current database schema, what CIDR ranges could we practically support (so that users of Special:Contributions would get a result within a reasonable amount of time)? This may require running some test queries. 1. Are there potential changes to the database schema that would let us support more of the ranges listed from question #1? 1. If the answer is yes, would it be feasible for us to make such changes (and worth the effort)? 1. Could we also list block information for the range, such as individual IPs and subranges within in? (You can see a current example at https://en.wikipedia.org/wiki/Special:Contributions/MusikPuppet4) 1. If the answer is yes, is there some way to show/hide the list, in the event there are say, 50 individual IP blocks within the range?

Epic at T145912 @bd808 had some solid ideas about how we could represent each IP (v4 or v6) as a unique value in an indexed column, which should make simple queries fairly fast. Let's hash out the details and come up with a plan. Currently the only useful index for this is a non-unique index on (rev_user_text, rev_timestamp) in the revision table. Let's answer the following questions: 1. What CIDR ranges would be useful to support searches for (both for IPv4 and IPv6)? This may require asking some administrators. 1. With the current database schema, what CIDR ranges could we practically support (so that users of Special:Contributions would get a result within a reasonable amount of time)? This may require running some test queries. 1. Are there potential changes to the database schema that would let us support more of the ranges listed from question #1? 1. If the answer is yes, would it be feasible for us to make such changes (and worth the effort)? 1. Could we also list block information for the range, such as individual IPs and/or subranges within in? (You can see a current example at https://en.wikipedia.org/wiki/Special:Contributions/MusikPuppet4) 1. If the answer is yes, is there some way to show/hide the list, in the event there are say, 50 individual IP blocks within the range?

Epic at T145912 @bd808 had some solid ideas about how we could represent each IP (v4 or v6) as a unique value in an indexed column, which should make simple queries fairly fast. Let's hash out the details and come up with a plan. Currently the only useful index for this is a non-unique index on (rev_user_text, rev_timestamp) in the revision table. Let's answer the following questions: 1. What CIDR ranges would be useful to support searches for (both for IPv4 and IPv6)? This may require asking some administrators. 1. With the current database schema, what CIDR ranges could we practically support (so that users of Special:Contributions would get a result within a reasonable amount of time)? This may require running some test queries. 1. Are there potential changes to the database schema that would let us support more of the ranges listed from question #1? 1. If the answer is yes, would it be feasible for us to make such changes (and worth the effort)? 1. Could we also list block information for the range, such as individual IPs and/or subranges within in? (You can see a current example at https://en.wikipedia.org/wiki/Special:Contributions/MusikPuppet4) 1. If the answer is yes, is there some way to show/hide the list, in the event there are say, 50 individual IP blocks within the range?