Suggestions for analyze patch required...

From: "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Suggestions for analyze patch required...
Date: 2004-01-11 16:05:05
Message-ID: 8F4A22E017460A458DB7BBAB65CA6AE502653B@openmanage
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi everyone,

In response to an email last year (see
http://archives.postgresql.org/pgsql-hackers/2003-10/msg00113.php for
more information), I'm beginning to write a patch for PostgreSQL to
enable people to write their own ANALYZE routines for user-defined
types. In terms of the PostgreSQL "itch and scratch" philosophy, the
main reason to do this is to allow PostGIS to update its geometric
histogram as part of the analyze process, instead of having to execute a
separate stored procedure on a regular basis. This is information is
then used as part of the GiST selectivity function to give PostgreSQL
the details needed to make the right decision about indexes.

The basic plan is as follows: to move the existing analysis function out
of analyze_rel() and assign it an OID, then assign that OID by default
to each type in the pg_types table. Finally analyze_rel() will be
modified to call the ANALYZE routine for the given OID in the type
table.

I've spent a few hours looking over the code but I have some questions
that I hope can be answered by members on this list (particularly core
team members!):

1) Is the basic plan above thinking along the right lines?

2) Should the statistical data for custom types be stored in the
pg_statistic table, or should it be the responsibility of the custom
type to store this in separate tables itself?

3) If pg_statistic is the best place to store the data, what would be
the most appropriate structure to send/receive from the custom analyze
function? It looks as if VacAttrStats would do the job, although I'm not
convinced that passing a non-datum/standard C types to a user function
is a good idea? And then also what would be appropriate values for the
other fields, in particular sta_kind, staopX and stanumbersX?

Many thanks,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446

This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-01-11 16:34:41 Re: libpq thread safety
Previous Message Manfred Spraul 2004-01-11 15:34:34 PQinSend question