Requested feature overview description.
Have a new search operator, possibly named poolsize, to allow users to search for images that are in pools of a given size. It should work something like the existing filesize operator - users can specify an exact size, and the site searches for that pool size, plus or minus epsilon, or users can specify greater-than or less-than a given post count.

Sample searches:

.wolf poolsize:10 anything tagged wolf and in a pool of (say) 9 to 11 images

.caracal poolsize:>19 anything tagged caracal and in a pool of 20 or more images

.lizard poolsize:<=6 anything tagged lizard and in a pool of 6 or fewer images

This operator should probably automatically imply inpool:true. That saves users from having to specify it, and it also would exclude posts that aren't in any pool. Otherwise, it would be a reasonable argument that poolsize:<3 should return images that are in pools of size 2, 1, or aren't in a pool at all, which is probably not what a user would expect.

Why would it be useful?
Mostly for users searching for comics, but potentially for any user who is interested in a series of related posts. If a user has a limited amount of time to browse e621, they might be interested in smaller pools and shorter stories. Or, if a user has plenty of time to browse, or wants to read a long, complex story, they might be interested in longer pools. This operator would allow for both use cases.

Having it be a number allows everyone to have their own idea of what a "small" or a "large" pool might be, rather than having an arbitrary operator (or tag) like small_pool or large_pool.

This proposal is based on this forum post .

Drawbacks:

This might cause extra database dips when searching, which may be undesirable in terms of query run time or CPU usage. The existing inpool operator apparently doesn't cause this kind of problem, but perhaps this operator would.

It's possible for a given post to be in more than one pool. It might not be clear which pool the poolsize operator should consider in that case.

What part(s) of the site page(s) are affected?
The post search box.

+1

I'd also like to suggest separate fave list strictly for favoriting an entire pool of art. There is a lot of artwork displayed in comic formats, and I imagine that users attempting to follow specific pool would be incredibly grateful for such an option. Also, would be really handy if someone just can't remember a specific art pools name, but want to re-look at an entire pool without searching a 1000+ fave list for one specific image.

grufurion said:
I'd also like to suggest separate fave list strictly for favoriting an entire pool of art. There is a lot of artwork displayed in comic formats, and I imagine that users attempting to follow specific pool would be incredibly grateful for such an option. Also, would be really handy if someone just can't remember a specific art pools name, but want to re-look at an entire pool without searching a 1000+ fave list for one specific image.

This won't be implemented, but a rough equivalent can be created with sets. You can store that info in the description of the set, the posts in the set, or both

Favoriting a pool sounds really cool though.

Like, you’d have separate "favorite posts" and "favorite pools" section on profiles.

Pools have their own IDs like posts do, so it could work, right?

dimoretpinel said:
Favoriting a pool sounds really cool though.

Like, you’d have separate "favorite posts" and "favorite pools" section on profiles.

Pools have their own IDs like posts do, so it could work, right?

"It could work" is not the same as "It will be implemented", something having an id doesn't will a feature into existence

The closest you're going to get is https://re621.app's subscription features, which works for tags, comments, forum topics, and pools

kora_viridian said:

It's possible for a given post to be in more than one pool. It might not be clear which pool the poolsize operator should consider in that case.

All of them, most likely. So if at least one of the pools fulfils the criteria it should be shown. We could have a poolnumber: operator for how many pools a post is in