Thread
-
Re: [HACKERS] Max size of data types and tuples. (fwd)
Darren King <darrenk@insightdist.com> — 1998-01-12T02:04:15Z
> > Here's a blast from the past. Shows how I keep those open issues in my > mailbox. > > Forwarded message: > > Date: Wed, 29 Jan 1997 13:38:10 -0500 > > From: aixssd!darrenk@abs.net (Darren King) > > To: hackers@postgreSQL.org > > Subject: [HACKERS] Max size of data types and tuples. Still buried in my 'received' box here too. Can't imagine all the bugs and/or issues you have kept in yours. > > 1. Clean up the #defines for the max block size. Currently, > > there are at least four references to 8192... Think I found and fixed all of these up. > > __These includes of storage/bufpage.h can be removed.__ Still _quite_ a few #includes that can be removed throughout. First, "utils/elog.h" and "util/palloc.h" are include in "postgres.h", so are unnecessary to include by themselves since "postgres.h" is include in _every_ .c file, correct? Also numerous #includes of "storage/bufpage.h" and "storage/fd.h" that are unnecessary since the things they were included for (BLCKSZ and SEEK_*) are now either in "config.h" or found in a system include file. > > 2. Once the block size issue is taken care of, calculate the > > maximum tuple size more accurately. ... > > 3. When #1 & #2 are resolved, let the textual fields have a max > > of (MAX_TUPLE_SIZE - sizeof(int)). This could be done as soon as I come up with a way of defining the packet size for the interfaces since this is the newest limiting factor. Peter's suggestion of backend functions for getting info might be the way to go. It would let the various interfaces get the info they need and would be a step towards JDBC and ODBC compliance. darrenk
-
Re: [HACKERS] Max size of data types and tuples. (fwd)
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-14T15:29:30Z
> > > > > Here's a blast from the past. Shows how I keep those open issues in my > > mailbox. > > > > Forwarded message: > > > Date: Wed, 29 Jan 1997 13:38:10 -0500 > > > From: aixssd!darrenk@abs.net (Darren King) > > > To: hackers@postgreSQL.org > > > Subject: [HACKERS] Max size of data types and tuples. > > Still buried in my 'received' box here too. Can't imagine all the bugs > and/or issues you have kept in yours. Not too bad now. > > > > > 1. Clean up the #defines for the max block size. Currently, > > > there are at least four references to 8192... > > Think I found and fixed all of these up. > > > > > __These includes of storage/bufpage.h can be removed.__ > > Still _quite_ a few #includes that can be removed throughout. First, > "utils/elog.h" and "util/palloc.h" are include in "postgres.h", so are > unnecessary to include by themselves since "postgres.h" is include in > _every_ .c file, correct? Yes, must be included. Period. Even 3rd party apps. > > Also numerous #includes of "storage/bufpage.h" and "storage/fd.h" that are > unnecessary since the things they were included for (BLCKSZ and SEEK_*) are > now either in "config.h" or found in a system include file. > > > > > 2. Once the block size issue is taken care of, calculate the > > > maximum tuple size more accurately. > ... > > > 3. When #1 & #2 are resolved, let the textual fields have a max > > > of (MAX_TUPLE_SIZE - sizeof(int)). > > This could be done as soon as I come up with a way of defining the packet > size for the interfaces since this is the newest limiting factor. > > Peter's suggestion of backend functions for getting info might be the way to > go. It would let the various interfaces get the info they need and would be > a step towards JDBC and ODBC compliance. Again, we could just set 3rd party apps to be the maximum tuple size we will ever have to support. -- Bruce Momjian maillist@candle.pha.pa.us
-
Re: [HACKERS] Max size of data types and tuples. (fwd)
Peter T Mount <psqlhack@maidast.demon.co.uk> — 1998-01-14T19:36:59Z
On Wed, 14 Jan 1998, Bruce Momjian wrote: > > This could be done as soon as I come up with a way of defining the packet > > size for the interfaces since this is the newest limiting factor. > > > > Peter's suggestion of backend functions for getting info might be the way to > > go. It would let the various interfaces get the info they need and would be > > a step towards JDBC and ODBC compliance. > > Again, we could just set 3rd party apps to be the maximum tuple size we > will ever have to support. Currently, were returning some defaults based on the 8K block size. Probably for these, we may be able to get away with the values we are setting. However, there are a few things that I think we will still need to implement as functions. -- Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk Main Homepage: http://www.demon.co.uk/finder Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
-
Re: [HACKERS] Max size of data types and tuples. (fwd)
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-14T21:27:24Z
> > On Wed, 14 Jan 1998, Bruce Momjian wrote: > > > > This could be done as soon as I come up with a way of defining the packet > > > size for the interfaces since this is the newest limiting factor. > > > > > > Peter's suggestion of backend functions for getting info might be the way to > > > go. It would let the various interfaces get the info they need and would be > > > a step towards JDBC and ODBC compliance. > > > > Again, we could just set 3rd party apps to be the maximum tuple size we > > will ever have to support. > > Currently, were returning some defaults based on the 8K block size. > > Probably for these, we may be able to get away with the values we are > setting. However, there are a few things that I think we will still need > to implement as functions. OK, let's decide soon, so people can be ready for Feb 1. -- Bruce Momjian maillist@candle.pha.pa.us
-
Re: [HACKERS] Max size of data types and tuples. (fwd)
Peter T Mount <psqlhack@maidast.demon.co.uk> — 1998-01-15T19:25:43Z
On Wed, 14 Jan 1998, Bruce Momjian wrote: > > On Wed, 14 Jan 1998, Bruce Momjian wrote: > > > > > > This could be done as soon as I come up with a way of defining the packet > > > > size for the interfaces since this is the newest limiting factor. > > > > > > > > Peter's suggestion of backend functions for getting info might be the way to > > > > go. It would let the various interfaces get the info they need and would be > > > > a step towards JDBC and ODBC compliance. > > > > > > Again, we could just set 3rd party apps to be the maximum tuple size we > > > will ever have to support. > > > > Currently, were returning some defaults based on the 8K block size. > > > > Probably for these, we may be able to get away with the values we are > > setting. However, there are a few things that I think we will still need > > to implement as functions. > > OK, let's decide soon, so people can be ready for Feb 1. I'm going to sort out what needs to be done to get us as close to compliance as possible over the next couple of days. Hopefully, we can decide on some of them then. -- Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk Main Homepage: http://www.demon.co.uk/finder Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
-
Re: [HACKERS] Max size of data types and tuples. (fwd)
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-22T02:49:00Z
Are we done with these issues, or are you still working on them, or is Peter working on this? > > > > > > > > > Here's a blast from the past. Shows how I keep those open issues in my > > > mailbox. > > > > > > Forwarded message: > > > > Date: Wed, 29 Jan 1997 13:38:10 -0500 > > > > From: aixssd!darrenk@abs.net (Darren King) > > > > To: hackers@postgreSQL.org > > > > Subject: [HACKERS] Max size of data types and tuples. > > > > Still buried in my 'received' box here too. Can't imagine all the bugs > > and/or issues you have kept in yours. > > Not too bad now. > > > > > > > > > 1. Clean up the #defines for the max block size. Currently, > > > > there are at least four references to 8192... > > > > Think I found and fixed all of these up. > > > > > > > > __These includes of storage/bufpage.h can be removed.__ > > > > Still _quite_ a few #includes that can be removed throughout. First, > > "utils/elog.h" and "util/palloc.h" are include in "postgres.h", so are > > unnecessary to include by themselves since "postgres.h" is include in > > _every_ .c file, correct? > > Yes, must be included. Period. Even 3rd party apps. > > > > > Also numerous #includes of "storage/bufpage.h" and "storage/fd.h" that are > > unnecessary since the things they were included for (BLCKSZ and SEEK_*) are > > now either in "config.h" or found in a system include file. > > > > > > > > 2. Once the block size issue is taken care of, calculate the > > > > maximum tuple size more accurately. > > ... > > > > 3. When #1 & #2 are resolved, let the textual fields have a max > > > > of (MAX_TUPLE_SIZE - sizeof(int)). > > > > This could be done as soon as I come up with a way of defining the packet > > size for the interfaces since this is the newest limiting factor. > > > > Peter's suggestion of backend functions for getting info might be the way to > > go. It would let the various interfaces get the info they need and would be > > a step towards JDBC and ODBC compliance. > > Again, we could just set 3rd party apps to be the maximum tuple size we > will ever have to support. > > > -- > Bruce Momjian > maillist@candle.pha.pa.us > > -- Bruce Momjian maillist@candle.pha.pa.us