Re: GiST: Need ideas on how to minimise data in a GiST index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GiST: Need ideas on how to minimise data in a GiST index
Date: 2003-03-24 15:34:17
Message-ID: 12891.1048520057@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

"Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> writes:
> However, each database column also has a spatial reference system
> identifier (SRID) that specifies the coordinate system the geometry is
> in. What should happen is that given two geometries or bounding boxes,
> an error should be generated whenever the SRIDs do not match.

Offhand I'm not sure why you think the index should solve this. It
seems more like grist for a CHECK constraint applied to the table.

One way to attack it without bloating the index is to consider the index
as lossy, meaning that the actual geometric operator must be reapplied
on each row identified by the index. Then the operator can compare
SRIDs, but you need not store SRIDs in the index.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-03-24 15:38:10 Re: fairly current mysql v postgresql comparison need for
Previous Message Mike Mascari 2003-03-24 15:18:39 Re: fairly current mysql v postgresql comparison need for

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Cave-Ayland 2003-03-24 16:17:01 Re: GiST: Need ideas on how to minimise data in a GiST index
Previous Message Tom Lane 2003-03-24 14:40:51 Re: A bad behavior under autocommit off mode