[kofrezo]

A filter on a supernet attribute, such as route_network=regexp(...), was rendered as a correlated EXISTS over server_inet_attribute with a second sublink on the server table to match the networks by hostname. Postgres evaluated it per candidate server, probing the server's address by key and only then testing containment, so the GiST index on server_inet_attribute.value could not drive the join.

Render the condition as "server.server_id IN (SELECT ...)" instead, driven from the matching networks' prefixes, the same shape #471 gave inherited supernet paths. Apply the hostname condition directly to the "supernet" alias, which is already a server row, instead of through a sublink. Both call sites share one helper so the join graph stays in a single place.

[kofrezo]

To give some context: The query in doubt being slow was route_network=regexp("servers[0-9]+-officeh-int") state=not(retired).

We traced it down via PostgreSQL log to this one (our database with our servertypes):

SELECT server.server_id, server.hostname, server.intern_ip, server.servertype_id
  FROM server
  WHERE EXISTS (SELECT 1 FROM server AS supernet JOIN server_inet_attribute AS server_addr ON (server_addr.server_id = server.server_id) JOIN server_inet_attribute AS net_addr ON (net_addr.value >>= server_addr.value AND
    net_addr.attribute_id = server_addr.attribute_id AND net_addr.server_id = supernet.server_id) WHERE supernet.servertype_id = 'route_network' AND supernet.server_id IN ( SELECT server_id FROM server WHERE hostname::text ~
    'servers[0-9]+-officeh-int'))
    AND (server.servertype_id IN ('tunnel_interface', 'hdmi_transmitter', 'floating_address', 'voip_phone', 'loadbalancer', 'hardware_external', 'hypervisor', 'room_tablet', 'router', 'switch', 'vm', 'blade_enclosure', 'vpn',
      'media_device', 'vm_external', 'camera', 'project_network', 'hardware', 'hw_internalrouter', 'doorlock', 'ipmi', 'nat_gateway', 'vlan_interface', 'accesspoint', 'printer', 'natbox', 'hw_loadbalancer'))
  ORDER BY server.hostname; 

It was especially costly on the CPU side due to the many joins doing filtering.

And this is where the LLM took over we simply asked it to do a root cause analyze in the query executor and suggest a faster way which it did by reordering the joins.

Result looks sane and is being tested.