Thread: papers on datatype design
Does anyone know of papers discussing issues that arise in the design of specific datatypes intended to represent particular real-world information? I am thinking of situations more complex than simply choosing among existing standard datatypes. In some instances, existing datatypes do not adequately represent the type of information required; therefore, additional design must be undertaken. To date, I have found essentially nothing on this issue. Any pointers would be extremely helpful. Thanks for your help. Cheers, Brook
[2001-12-07 22:58] Brook Milligan said: | Does anyone know of papers discussing issues that arise in the design | of specific datatypes intended to represent particular real-world | information? I am thinking of situations more complex than simply | choosing among existing standard datatypes. In some instances, | existing datatypes do not adequately represent the type of information | required; therefore, additional design must be undertaken. | | To date, I have found essentially nothing on this issue. Any pointers | would be extremely helpful. PostgreSQL has a /very/ nice system of creating user-defined types, however I am not aware of any papers directly related to design of user-defined types for PostgreSQL. There are numerous examples available in the contrib/ directory of all recent PostgreSQL releases. I'd recommend reading over relevant documentation[1] to familiarize yourself with PG's type facilities, then take a look at some of the user-defined types in contrib/ to see some "real-world" user-defined types. [1] http://developer.postgresql.org/docs/postgres/type-system.html http://developer.postgresql.org/docs/postgres/xtypes.html cheers. brent -- "Develop your talent, man, and leave the world something. Records are really gifts from people. To think that an artist would love you enough to share his music with anyone is a beautiful thing." -- Duane Allman
Ever since I upgraded to 7.0 or 7.1.3 (sorry can't remember which one), I've been getting notices from the vacuum command about overflowing proc registers and invalid pointers that didn't appear before. I was just wondering if this was normal, or if I have something configured wrong. I'm starting the postmaster with /usr/local/pgsql/bin/postmaster -B 212890 -N 256 -i -o "-F" > /var/log/postgres 2>&1 The machine is dual proc, 2GB RAM, RH Linux 6.2. (A secondary question I have here is whether -B specifies the total amount of RAM to be used for buffers for all postmaster processes, or the amount of RAM for EACH process. If for each, then this number is way to high in my case.) I'm running "vacuum" first with no arguments, then "vacuum analyze". I'm not sure why I'm doing that, but I vaguely remember in an earlier version of postgres, the vacuum analyze command would sometimes never complete, unless I ran vacuum with no args first. Maybe it no longer behaves this way. Anyway, the messages are... Vacuuming (These messages I receive every night) NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: InvalidateSharedInvalid: cache state reset NOTICE: RegisterSharedInvalid: SI buffer overflow NOTICE: InvalidateSharedInvalid: cache state reset (These messages or similiar messages about invalid pointers, I'm sure I started receiving after upgrading to 7.1.3 and they occur less often, maybe once every two weeks. A couple weeks ago, I received messages somewhat similiar to these upon doing a query upon certain tables, and I had to rebuild the database from backups.) NOTICE: Rel r_maryland: Uninitialized page 730 - fixing NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 4) - fixing NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 8) - fixing NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 6) - fixing NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 2) - fixing NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 5) - fixing NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 7) - fixing NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 1) - fixing NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 3) - fixing NOTICE: Index cfsmakemaryland: pointer to EmptyPage (blk 730 off 3) - fixing NOTICE: Index cfsmakemaryland: pointer to EmptyPage (blk 730 off 6) - fixing NOTICE: Index cfsmakemaryland: pointer to EmptyPage (blk 730 off 2) - fixing NOTICE: Index cfsmakemaryland: pointer to EmptyPage (blk 730 off 4) - fixing NOTICE: Index cfsmakemaryland: pointer to EmptyPage (blk 730 off 5) - fixing etc... (snipped the other 5 pages of these notices) Thanks much, Rich
PostgreSQL has a /very/ nice system of creating user-defined types, I guess I was not clear. I am very aware of PostgreSQL's excellent type system and have written several types myself. However, I am looking for something broader: published papers in the database literature on the rationale for and design of datatypes that go beyond the "standard" set to represent more complex "real-world" information. I understand this is not necessarily PostgreSQL-specific, but I expect that there are people here more knowledgable of the database literature than myself and that PostgreSQL's extensible type system might attract people who have given the issue some thought. Sorry if this is too off-topic. Cheers, Brook
Brook Milligan <brook@biology.nmsu.edu> writes: > I guess I was not clear. I am very aware of PostgreSQL's excellent > type system and have written several types myself. However, I am > looking for something broader: published papers in the database > literature on the rationale for and design of datatypes that go beyond > the "standard" set to represent more complex "real-world" > information. I understand this is not necessarily Perhaps some readings on object-oriented programming and design can be useful. Also, C.J. Date [1] dedicates a complete chapter to the subject (19 inheritance of types), in spite of the name of the chapter, it seems the to be the closest thing for what you want. Regards, Manuel. [1] Date C.J., An introduction to database systems 7th editon
Manuel Sugawara wrote: >Brook Milligan <brook@biology.nmsu.edu> writes: > >>I guess I was not clear. I am very aware of PostgreSQL's excellent >>type system and have written several types myself. However, I am >>looking for something broader: published papers in the database >>literature on the rationale for and design of datatypes that go beyond >>the "standard" set to represent more complex "real-world" >>information. I understand this is not necessarily >> > >Perhaps some readings on object-oriented programming and design can >be useful. Also, C.J. Date [1] dedicates a complete chapter to >the subject (19 inheritance of types), in spite of the name of the >chapter, it seems the to be the closest thing for what you want. > >Regards, >Manuel. > >[1] Date C.J., An introduction to database systems 7th editon > >---------------------------(end of broadcast)--------------------------- >TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > If you looking for white paper material on general storage of information and its structure check out the current edition of the IBM Systems Journal on the newsstands. Its a little spendy but this quarters issue all about knowledge storage. - Bill
"Rich Ryan" <rich@usedcars.com> writes:
> Vacuuming
> (These messages I receive every night)
> NOTICE: RegisterSharedInvalid: SI buffer overflow
> NOTICE: RegisterSharedInvalid: SI buffer overflow
> NOTICE: InvalidateSharedInvalid: cache state reset
These are ignorable.
> NOTICE: Rel r_maryland: Uninitialized page 730 - fixing
> NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 4) - fixing
> NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 8) - fixing
These are not good. Is it possible you've got disk hardware problems?
A possible answer is to rebuild that damaged index with REINDEX, but if
the problems keep coming back then you've got something very wrong.
regards, tom lane
I delete rows and indexes, then copy in new rows, then create the indexes
over again every night, so that should be equivalent to rebuild. It's
possible my disk has some bad blocks on it. These errors only happen every
once in awhile, so I"ll change the DB to a different disk and see what
happens.
Thanks,
Rich
> NOTICE: Rel r_maryland: Uninitialized page 730 - fixing
> NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 4) -
fixing
> NOTICE: Index cfsoidmaryland: pointer to EmptyPage (blk 730 off 8) -
fixing
>These are not good. Is it possible you've got disk hardware problems?
>A possible answer is to rebuild that damaged index with REINDEX, but if
>the problems keep coming back then you've got something very wrong.
>regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)