Classical modular form page won't load

[AndrewVSutherland]

The page http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/23/6/2/ times out and produces a 502 error (also on beta).

[sehlen]

This is caused by a large record (the file in gridfs is 50MB). Issues like this are all over the place but are solved by creating a smaller record which I'll do systematically when updating all of the data.

However, what is strange is that when I just created a much smaller record for 23.6.2.a, it still times out on beta and loads but takes quite a while if I run it locally. Could this have to do with mongo being busy replicating my update of the dimension table? I just stopped the update (all records that we actually do have in the db are changed anyway, the dimension table has records for high level spaces, which is ok I guess but it just seems to takes a long time to update all the records. I guess I might have to drop the indices - was that one of the things you learned from the other larger updates you and others have been working on? I haven't followed the whole discussion and maybe you can just give me a quick advice here.

(What I want to do (as described in my other post) is to add a field to all records that are missing it, namely the space_orbit_label, which should by default be level.weight.i, where i is the smallest number appearing in the list of numbers of characters in the same Galois orbit. This had been added at some point and is a good field for indexing (I want to index it as being "unique" in fact to avoid duplicates which we have right now and having it will make it easy to remove the duplicates as the character_galois_orbit field (a list) apparently can appear with different orderings in the db!)

[sehlen]

But there are certainly also some other issues here because for this particular form (the number field has degree 90 over Q), the function determining if the q-expansion should be hidden or not takes 10s ;-) So we have to save that in the db! I will include this into the list of things I need to prepare before we recompute/fix the data.

[AndrewVSutherland]

@sehlen -- The advice I gave to others was to rewrite all the records to a new collection (with no indexes on it) and to then create the indexes, and I provided a utility function to do this (see https://github.com/LMFDB/lmfdb/blob/master/data_mgt/utilities/rewrite.py). When this has completed you can rename the collections to replace the old one with the new one (this takes no time).

Regarding your question about replication, unless you are setting the write_concern explicitly, mongo db should be throttling your updates to a rate where it can keep up with replication. But updating data in place (and especially maintaining the indices) is expensive, and mongo db is not very clever about locking (it appears to lock your entire database during certain index operations -- possibly when it needs to allocate new index pages), and this can definitely impact read performance elsewhere, even when you are not reading the same records (or even necessarily from the same collection).

Regarding time spent deciding whether or not to hide the q-expansion, why not just look at the dimension (which is stored as a separate attribute), if it is greater than some moderate value (e.g. 10 or 20, or whatever you think makes sense) then hide the q-expansion. That should take no time to figure out.

[fredstro]

@sehlen I assume that setting the space_orbit_label to be unique means that we will only store one space per galois orbit. And make sure that you are recreateing it everywhere to avoid confusion since it used to be defined as N.k.j with j being the index of the galois orbit of the character in the list of all galois orbits.

On Wed, 25 May 2016 03:59 Andrew Sutherland, notifications@github.com wrote:

@sehlen https://github.com/sehlen -- The advice I gave to others was to rewrite all the records to a new collection (with no indexes on it) and to then create the indexes, and I provided a utility function to do this (see https://github.com/LMFDB/lmfdb/blob/master/data_mgt/utilities/rewrite.py). When this has completed you can rename the collections to replace the old one with the new one (this takes no time).

Regarding your question about replication, unless you are setting the write_concern explicitly, mongo db should be throttling your rates to a rate where it can keep up with replication. But updating data in place (and especially maintaining the indices) is expensive, and mongo db is not very clever about locking (it appears to lock your entire database during certain index operations -- possibly when it needs to allocate new index pages), and this can definitely impact read performance elsewhere, even when you are not reading the same records (or even necessarily from the same collection).

Regarding the function deciding whether to hid the q-expansion, why not just look at the dimension (which is stored as a separate attribute), if it is greater than some moderate value (e.g. 10 or 20, or whatever you think makes sense) I think you definitely want to hide the q-expansion. That should take no time to figure out.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221460951

[sehlen]

On Wed, May 25, 2016, 05:53 Fredrik Strömberg notifications@github.com wrote:

@sehlen I assume that setting the space_orbit_label to be unique means that we will only store one space per galois orbit.

@Fredstro

That's what we do right now, no? I think I argued for having all of them at some point but now it seems just like a waste of space since the records get so large so easily.

And make sure that you are recreateing it everywhere to avoid confusion

since it used to be defined as N.k.j with j being the index of the galois orbit of the character in the list of all galois orbits.

Are you sure? I stopped the process yesterday and I guess I might have misunderstood it and have to update all now anyway. I'll look at the records again later. But many many records did not have it and there are quite a few duplicates in the dimension table causing the whole Galois orbit of characters to appear twice on the page.

On Wed, 25 May 2016 03:59 Andrew Sutherland, notifications@github.com wrote:

@sehlen https://github.com/sehlen -- The advice I gave to others was to rewrite all the records to a new collection (with no indexes on it) and to then create the indexes, and I provided a utility function to do this (see https://github.com/LMFDB/lmfdb/blob/master/data_mgt/utilities/rewrite.py ). When this has completed you can rename the collections to replace the old one with the new one (this takes no time).

Regarding your question about replication, unless you are setting the write_concern explicitly, mongo db should be throttling your rates to a rate where it can keep up with replication. But updating data in place (and especially maintaining the indices) is expensive, and mongo db is not very clever about locking (it appears to lock your entire database during certain index operations -- possibly when it needs to allocate new index pages), and this can definitely impact read performance elsewhere, even when you are not reading the same records (or even necessarily from the same collection).

Regarding the function deciding whether to hid the q-expansion, why not just look at the dimension (which is stored as a separate attribute), if it is greater than some moderate value (e.g. 10 or 20, or whatever you think makes sense) I think you definitely want to hide the q-expansion. That should take no time to figure out.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221460951

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221526688

[fredstro]

@sehlen I see now, you are probably right. It seems that I was thinking of the ‘space_orbit_label’. I don’t know how the duplicates came about in the dimension table. In the ‘WebModFormSpace_computing.update_dimension_table()’ routine we always check for an existing ‘space_label’ first. But of course, since we haven’t used indexing it could happen that this table has been updated from a separate script (or command line) where I/we forgot about checking for existing records...

On 25 May 2016, at 11:36, Stephan Ehlen notifications@github.com wrote:

On Wed, May 25, 2016, 05:53 Fredrik Strömberg notifications@github.com wrote:

@sehlen I assume that setting the space_orbit_label to be unique means that we will only store one space per galois orbit.

@Fredstro

That's what we do right now, no? I think I argued for having all of them at some point but now it seems just like a waste of space since the records get so large so easily.

And make sure that you are recreateing it everywhere to avoid confusion

since it used to be defined as N.k.j with j being the index of the galois orbit of the character in the list of all galois orbits.

Are you sure? I stopped the process yesterday and I guess I might have misunderstood it and have to update all now anyway. I'll look at the records again later. But many many records did not have it and there are quite a few duplicates in the dimension table causing the whole Galois orbit of characters to appear twice on the page.

On Wed, 25 May 2016 03:59 Andrew Sutherland, notifications@github.com wrote:

@sehlen https://github.com/sehlen -- The advice I gave to others was to rewrite all the records to a new collection (with no indexes on it) and to then create the indexes, and I provided a utility function to do this (see https://github.com/LMFDB/lmfdb/blob/master/data_mgt/utilities/rewrite.py ). When this has completed you can rename the collections to replace the old one with the new one (this takes no time).

Regarding your question about replication, unless you are setting the write_concern explicitly, mongo db should be throttling your rates to a rate where it can keep up with replication. But updating data in place (and especially maintaining the indices) is expensive, and mongo db is not very clever about locking (it appears to lock your entire database during certain index operations -- possibly when it needs to allocate new index pages), and this can definitely impact read performance elsewhere, even when you are not reading the same records (or even necessarily from the same collection).

Regarding the function deciding whether to hid the q-expansion, why not just look at the dimension (which is stored as a separate attribute), if it is greater than some moderate value (e.g. 10 or 20, or whatever you think makes sense) I think you definitely want to hide the q-expansion. That should take no time to figure out.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221460951

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221526688

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221535877

[sehlen]

@Fredstro: making this check is not enough given the current template(s). You'll end up with different spaces having the same galois orbit entry but possibly even in a different order (it's a sequence and it is not being sorted). They show up several times on the page for Gamma1 (and in that way it's a duplicate), possibly in different orderings. That's why I wanted the space_orbit_label (you repeated this one now even though you were saying I might be right ;-) to be present for all of them since a query for when these are the same will be simpler (to delete the duplicates) than for the unordered list.

On Wed, May 25, 2016, 06:45 Fredrik Strömberg notifications@github.com wrote:

@sehlen I see now, you are probably right. It seems that I was thinking of the ‘space_orbit_label’. I don’t know how the duplicates came about in the dimension table. In the ‘WebModFormSpace_computing.update_dimension_table()’ routine we always check for an existing ‘space_label’ first. But of course, since we haven’t used indexing it could happen that this table has been updated from a separate script (or command line) where I/we forgot about checking for existing records...

On 25 May 2016, at 11:36, Stephan Ehlen notifications@github.com wrote:

On Wed, May 25, 2016, 05:53 Fredrik Strömberg notifications@github.com wrote:

@sehlen I assume that setting the space_orbit_label to be unique means that we will only store one space per galois orbit.

@Fredstro

That's what we do right now, no? I think I argued for having all of them at some point but now it seems just like a waste of space since the records get so large so easily.

And make sure that you are recreateing it everywhere to avoid confusion

since it used to be defined as N.k.j with j being the index of the galois orbit of the character in the list of all galois orbits.

Are you sure? I stopped the process yesterday and I guess I might have misunderstood it and have to update all now anyway. I'll look at the records again later. But many many records did not have it and there are quite a few duplicates in the dimension table causing the whole Galois orbit of characters to appear twice on the page.

On Wed, 25 May 2016 03:59 Andrew Sutherland, <notifications@github.com

wrote:

@sehlen https://github.com/sehlen -- The advice I gave to others was to rewrite all the records to a new collection (with no indexes on it) and to then create the indexes, and I provided a utility function to do this (see

https://github.com/LMFDB/lmfdb/blob/master/data_mgt/utilities/rewrite.py ). When this has completed you can rename the collections to replace the old one with the new one (this takes no time).

Regarding your question about replication, unless you are setting the write_concern explicitly, mongo db should be throttling your rates to a rate where it can keep up with replication. But updating data in place (and especially maintaining the indices) is expensive, and mongo db is not very clever about locking (it appears to lock your entire database during certain index operations -- possibly when it needs to allocate new index pages), and this can definitely impact read performance elsewhere, even when you are not reading the same records (or even necessarily from the same collection).

Regarding the function deciding whether to hid the q-expansion, why not just look at the dimension (which is stored as a separate attribute), if it is greater than some moderate value (e.g. 10 or 20, or whatever you think makes sense) I think you definitely want to hide the q-expansion. That should take no time to figure out.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221460951

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221526688

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221535877>

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221537654

[fredstro]

@sehlen: I see, I was confused since I was obviously correct in that ‘space_orbit_label’ denotes the number of the orbit in the list of all orbits I assumed that you were referring to something else… in the class we are defining it in terms of the function conrey_character_number_to_conrey_galois_orbit_number and it seems that you haven’t changed this definition in web_modform_space_computing.py so you should do that as well.

I am not sure why the list is not unique. We are not sorting this sequence but we call self.character.character.galois_orbit() and this sequence given by the class DirichletGroupConrey should be sorted (or at least consistently unsorted)

On 25 May 2016, at 11:52, Stephan Ehlen notifications@github.com wrote:

@Fredstro: making this check is not enough given the current template(s). You'll end up with different spaces having the same galois orbit entry but possibly even in a different order (it's a sequence and it is not being sorted). They show up several times on the page for Gamma1 (and in that way it's a duplicate), possibly in different orderings. That's why I wanted the space_orbit_label (you repeated this one now even though you were saying I might be right ;-) to be present for all of them since a query for when these are the same will be simpler (to delete the duplicates) than for the unordered list.

On Wed, May 25, 2016, 06:45 Fredrik Strömberg notifications@github.com wrote:

@sehlen I see now, you are probably right. It seems that I was thinking of the ‘space_orbit_label’. I don’t know how the duplicates came about in the dimension table. In the ‘WebModFormSpace_computing.update_dimension_table()’ routine we always check for an existing ‘space_label’ first. But of course, since we haven’t used indexing it could happen that this table has been updated from a separate script (or command line) where I/we forgot about checking for existing records...

On 25 May 2016, at 11:36, Stephan Ehlen notifications@github.com wrote:

On Wed, May 25, 2016, 05:53 Fredrik Strömberg notifications@github.com wrote:

@sehlen I assume that setting the space_orbit_label to be unique means that we will only store one space per galois orbit.

@Fredstro

That's what we do right now, no? I think I argued for having all of them at some point but now it seems just like a waste of space since the records get so large so easily.

And make sure that you are recreateing it everywhere to avoid confusion

since it used to be defined as N.k.j with j being the index of the galois orbit of the character in the list of all galois orbits.

Are you sure? I stopped the process yesterday and I guess I might have misunderstood it and have to update all now anyway. I'll look at the records again later. But many many records did not have it and there are quite a few duplicates in the dimension table causing the whole Galois orbit of characters to appear twice on the page.

On Wed, 25 May 2016 03:59 Andrew Sutherland, <notifications@github.com

wrote:

@sehlen https://github.com/sehlen -- The advice I gave to others was to rewrite all the records to a new collection (with no indexes on it) and to then create the indexes, and I provided a utility function to do this (see

https://github.com/LMFDB/lmfdb/blob/master/data_mgt/utilities/rewrite.py ). When this has completed you can rename the collections to replace the old one with the new one (this takes no time).

Regarding your question about replication, unless you are setting the write_concern explicitly, mongo db should be throttling your rates to a rate where it can keep up with replication. But updating data in place (and especially maintaining the indices) is expensive, and mongo db is not very clever about locking (it appears to lock your entire database during certain index operations -- possibly when it needs to allocate new index pages), and this can definitely impact read performance elsewhere, even when you are not reading the same records (or even necessarily from the same collection).

Regarding the function deciding whether to hid the q-expansion, why not just look at the dimension (which is stored as a separate attribute), if it is greater than some moderate value (e.g. 10 or 20, or whatever you think makes sense) I think you definitely want to hide the q-expansion. That should take no time to figure out.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221460951

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221526688

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221535877>

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221537654

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221538936

[sehlen]

@fredstro: ok, my bad. I'm not sure how it should be but I'll take a look in a bit.

On Wed, May 25, 2016, 07:02 Fredrik Strömberg notifications@github.com wrote:

@sehlen: I see, I was confused since I was obviously correct in that ‘space_orbit_label’ denotes the number of the orbit in the list of all orbits I assumed that you were referring to something else… in the class we are defining it in terms of the function conrey_character_number_to_conrey_galois_orbit_number and it seems that you haven’t changed this definition in web_modform_space_computing.py so you should do that as well.

I am not sure why the list is not unique. We are not sorting this sequence but we call self.character.character.galois_orbit() and this sequence given by the class DirichletGroupConrey should be sorted (or at least consistently unsorted)

On 25 May 2016, at 11:52, Stephan Ehlen notifications@github.com wrote:

@Fredstro: making this check is not enough given the current template(s). You'll end up with different spaces having the same galois orbit entry but possibly even in a different order (it's a sequence and it is not being sorted). They show up several times on the page for Gamma1 (and in that way it's a duplicate), possibly in different orderings. That's why I wanted the space_orbit_label (you repeated this one now even though you were saying I might be right ;-) to be present for all of them since a query for when these are the same will be simpler (to delete the duplicates) than for the unordered list.

On Wed, May 25, 2016, 06:45 Fredrik Strömberg notifications@github.com wrote:

@sehlen I see now, you are probably right. It seems that I was thinking of the ‘space_orbit_label’. I don’t know how the duplicates came about in the dimension table. In the ‘WebModFormSpace_computing.update_dimension_table()’ routine we always check for an existing ‘space_label’ first. But of course, since we haven’t used indexing it could happen that this table has been updated from a separate script (or command line) where I/we forgot about checking for existing records...

On 25 May 2016, at 11:36, Stephan Ehlen notifications@github.com wrote:

On Wed, May 25, 2016, 05:53 Fredrik Strömberg < notifications@github.com> wrote:

@sehlen I assume that setting the space_orbit_label to be unique means that we will only store one space per galois orbit.

@Fredstro

That's what we do right now, no? I think I argued for having all of them at some point but now it seems just like a waste of space since the records get so large so easily.

And make sure that you are recreateing it everywhere to avoid confusion

since it used to be defined as N.k.j with j being the index of the galois orbit of the character in the list of all galois orbits.

Are you sure? I stopped the process yesterday and I guess I might have misunderstood it and have to update all now anyway. I'll look at the records again later. But many many records did not have it and there are quite a few duplicates in the dimension table causing the whole Galois orbit of characters to appear twice on the page.

On Wed, 25 May 2016 03:59 Andrew Sutherland, < notifications@github.com

wrote:

@sehlen https://github.com/sehlen -- The advice I gave to others was to rewrite all the records to a new collection (with no indexes on it) and to then create the indexes, and I provided a utility function to do this (see

https://github.com/LMFDB/lmfdb/blob/master/data_mgt/utilities/rewrite.py

).

When this has completed you can rename the collections to replace the old one with the new one (this takes no time).

Regarding your question about replication, unless you are setting the write_concern explicitly, mongo db should be throttling your rates to a rate where it can keep up with replication. But updating data in place (and especially maintaining the indices) is expensive, and mongo db is not very clever about locking (it appears to lock your entire database during certain index operations -- possibly when it needs to allocate new index pages), and this can definitely impact read performance elsewhere, even when you are not reading the same records (or even necessarily from the same collection).

Regarding the function deciding whether to hid the q-expansion, why not just look at the dimension (which is stored as a separate attribute), if it is greater than some moderate value (e.g. 10 or 20, or whatever you think makes sense) I think you definitely want to hide the q-expansion. That should take no time to figure out.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221460951>

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub <https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221526688

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221535877>

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221537654

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221538936>

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221540789

[fredstro]

@sehlen: well I was confusing things from the beginning… I hope that if I leave you alone with this for a while all records will be consistent :) And I really appreciate that you are cleaning it up, just make sure that all these properties are documented (something which I have probably been very bad with)

On 25 May 2016, at 12:08, Stephan Ehlen notifications@github.com wrote:

@fredstro: ok, my bad. I'm not sure how it should be but I'll take a look in a bit.

On Wed, May 25, 2016, 07:02 Fredrik Strömberg notifications@github.com wrote:

@sehlen: I see, I was confused since I was obviously correct in that ‘space_orbit_label’ denotes the number of the orbit in the list of all orbits I assumed that you were referring to something else… in the class we are defining it in terms of the function conrey_character_number_to_conrey_galois_orbit_number and it seems that you haven’t changed this definition in web_modform_space_computing.py so you should do that as well.

I am not sure why the list is not unique. We are not sorting this sequence but we call self.character.character.galois_orbit() and this sequence given by the class DirichletGroupConrey should be sorted (or at least consistently unsorted)

On 25 May 2016, at 11:52, Stephan Ehlen notifications@github.com wrote:

@Fredstro: making this check is not enough given the current template(s). You'll end up with different spaces having the same galois orbit entry but possibly even in a different order (it's a sequence and it is not being sorted). They show up several times on the page for Gamma1 (and in that way it's a duplicate), possibly in different orderings. That's why I wanted the space_orbit_label (you repeated this one now even though you were saying I might be right ;-) to be present for all of them since a query for when these are the same will be simpler (to delete the duplicates) than for the unordered list.

On Wed, May 25, 2016, 06:45 Fredrik Strömberg notifications@github.com wrote:

@sehlen I see now, you are probably right. It seems that I was thinking of the ‘space_orbit_label’. I don’t know how the duplicates came about in the dimension table. In the ‘WebModFormSpace_computing.update_dimension_table()’ routine we always check for an existing ‘space_label’ first. But of course, since we haven’t used indexing it could happen that this table has been updated from a separate script (or command line) where I/we forgot about checking for existing records...

On 25 May 2016, at 11:36, Stephan Ehlen notifications@github.com wrote:

On Wed, May 25, 2016, 05:53 Fredrik Strömberg < notifications@github.com> wrote:

@sehlen I assume that setting the space_orbit_label to be unique means that we will only store one space per galois orbit.

@Fredstro

That's what we do right now, no? I think I argued for having all of them at some point but now it seems just like a waste of space since the records get so large so easily.

And make sure that you are recreateing it everywhere to avoid confusion

since it used to be defined as N.k.j with j being the index of the galois orbit of the character in the list of all galois orbits.

Are you sure? I stopped the process yesterday and I guess I might have misunderstood it and have to update all now anyway. I'll look at the records again later. But many many records did not have it and there are quite a few duplicates in the dimension table causing the whole Galois orbit of characters to appear twice on the page.

On Wed, 25 May 2016 03:59 Andrew Sutherland, < notifications@github.com

wrote:

@sehlen https://github.com/sehlen -- The advice I gave to others was to rewrite all the records to a new collection (with no indexes on it) and to then create the indexes, and I provided a utility function to do this (see

https://github.com/LMFDB/lmfdb/blob/master/data_mgt/utilities/rewrite.py

).

When this has completed you can rename the collections to replace the old one with the new one (this takes no time).

Regarding your question about replication, unless you are setting the write_concern explicitly, mongo db should be throttling your rates to a rate where it can keep up with replication. But updating data in place (and especially maintaining the indices) is expensive, and mongo db is not very clever about locking (it appears to lock your entire database during certain index operations -- possibly when it needs to allocate new index pages), and this can definitely impact read performance elsewhere, even when you are not reading the same records (or even necessarily from the same collection).

Regarding the function deciding whether to hid the q-expansion, why not just look at the dimension (which is stored as a separate attribute), if it is greater than some moderate value (e.g. 10 or 20, or whatever you think makes sense) I think you definitely want to hide the q-expansion. That should take no time to figure out.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221460951>

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub <https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221526688

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221535877>

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221537654

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub < https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221538936>

— You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221540789

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/LMFDB/lmfdb/issues/1454#issuecomment-221541961

[AndrewVSutherland]

The fix is now live on www.lmfdb.org, the page http://www.lmfdb.org/ModularForm/GL2/Q/holomorphic/23/6/2/ loads now.