<para>

When order is smaller than smoc's maximal order, the MOC resolution

is degraded to the new order, and its maximal order is set to that

order. When order is larger than the smoc's maximal order, smoc's

shape is not modified, but its maximal order is raised to order.

</para>

<type>smoc</type> union and intersection are available as aggregate functions

that compute the aggretated area over a given column.

<example>

<title>Computing the overall coverage of a catalog</title>

<programlisting>

<![CDATA[SELECT sum(coverage) FROM ivoa;]]>

<![CDATA[ sum]]>

<![CDATA[-----------]]>

<![CDATA[ 0/0-11 6/]]>

</programlisting>

</example>

linkend="op.over"><literal>@&gt;</literal></link>, <link

linkend="op.equal"><literal>&lt;&gt;</literal></link>.

</para>

<para>

The index works by casting all contained smocs to a fixed level, and

for each pixel at that level, storing which smocs overlap with that

pixel. This is especially beneficial for "overlaps" queries using

the <literal>&amp;&amp;</literal> operator. Two levels of granularity

are provided: the default opclass <literal>smoc_gin_ops</literal>

works on level 5 with a resolution of 12288 pixels, while the

opclass <literal>smoc_gin_ops_fine</literal> works on level 8 with

786432 pixels. The downside of that approach is that storing large

smocs like "all sky" (<literal>0/0-11</literal>) produces a large

number of index entries.

<![CDATA[-- Alternative index with more detail]]>

<![CDATA[CREATE INDEX ivoa_fine_idx ON ivoa USING GIN (coverage smoc_gin_ops_fine);]]>

<para>

A unique feature of MOCs compared to the other

<application>pgSphere</application>

objects is that their unions and intersections are again MOCs.

Hence, smocs support two special operators which both yield

<type>smoc</type> as output:

</para>

tessellation, yielding pixels of different size. At level 0, the

sky is divided into 12 pixels numbered 0 to 11. At the maximally

defined level 29, there are 12 * 4^29 = 3458764513820540928

pixels.