The answer from tinlyx already said that with PostgreSQL the page size is always 8k when you don´t change it (which you should´nt without knowing exactly what you are doing).
But i will try to give some background explanation about it for better understanding. But i do not know how the implementation in PostgreSQL and PostGIS is in the very detail as i´m no programmer.
A page in general is the way data is safed and used in memory allocation and even in the registers of the processor. Each page has some header with some general information and then the data. in PostgreSQL each row is a page. When a row has more information as 8k the row is split into multiple pages, wich only affects performance and complicates the background stuff for the software. But an index can´t have a branch-object in more than one page. The documentation might be a bit unfortunatly worded as it tells from a general problem that does not occur with spatial data in an R-Tree as all objects are only used as their bounding boxes.
The background is complicated, especially how the software balances the tree and how that affects the size of the index and performance.
But a few keywords that might help you with the general idea:
- Indeces are made to find objects, without it all data would need to be scanned sequential to find a single value; for spatial data it means for example that to check for overlapping polygons all polygons would have to be checked against each other
- a tree index means that it starts from a root towards branches and subbranches
the index used here is a R-Tree, which sorts spatial data based on their bounding boxes (r - for rectangle); this way the check for overlapping is done only between few rectangles and in case of overlapping it heads further on in the tree until it finds a single object (the leaf); all objects in the non-overlapping rectangles don´t need to be scanned anymore
each branch might have different amount of objects in it, the index (or the software implementation) tries to fill as many objects into it as the page size allows by growing the bounding rectangle of the branch around the objects without touching the other branches
the index also tries to sort the data to have as few subbranches as possible and to have as few overlappings in the boundingboxes for the branches for each index-level; both is important for the performance of the index
this sorting is done by the software that implements the GiST; PostgreSQL is one implemention and offers an API to access this "sorting-program"; PostGIS don´t uses the PostgreSQL R-Tree but building its own using the given API from PostgreSQL
losiness only means that objects might be compressed using lossy compression (like with JPEG) for the use in the index; as spatial data is only used as bounding-boxes that does not mean anything in this context here