Re: [DOCS] Words missing in the following txt
On Sun, Dec 26, 2010 at 8:28 PM, Leslie S Satenstein wrote: > In 8.1.1. Integer Types > > The ending sentence in the 2nd paragraph reads... > > The bigint type should only be used if the integer range is insufficient, > because the latter is definitely faster. > > Integers are bigger or smaller, the sentence could read better if phrased as > follows: > > Use regular integers for fast efficient execution. The bigint type should > only be used if the integer range is insufficient. The original phrasing might be a little too cute in the sense that "the latter" could be taken to refer to "the integer range" rather than "the integer data type", but the intended meaning is pretty obvious in context. I think your revised phrasing is more negative about bigints than we actually want to be. I think bigints also provide fast, efficient execution (compare with, say, numeric) but they are not AS fast as integers. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Some comments about Julian Dates and possible bug. Please provide feedback.
On Mon, Dec 27, 2010 at 9:23 PM, Leslie S Satenstein wrote: > I found the Julian date code that is programmed in Postgres, to be accurate > and fast except for one situation. But, I do have one or two questions. 1) > Which calendar is being used? > > In the Gregorian Calendar, January 1, 0001 is lowest positive date. > The day before 1/1/0001, according to the Gregorian calendar is December > 31,-0001 in which the year has a value of negative one --- there is no zero > year in the Gregorian Calendar. (zero year is an error) > > I tested and found the algorithm in Postgres to have the day before January > 1,0001 calculating as December 31, even though the world calculates the > day before January 1,0001 as December 31,-0001. > > 2) Is the algorithm in Postgres correct? I think not, as the calculations > for the difference in days between January 1, 0001 and December 31,-0001 is > not 367 days, but just the value 1. > > To convert the code to work with the Gregorian calendar takes two fixes to > two sub-routines. Each fix is two lines of C code. > > I have tested the PG Date C language routines with/without my fix, starting > with the year around -4713 to several centuries into the future. As long as > both versions calculate Julian dates that are later than 1/1/0001, both the > PG and my fixed versions respecting Gregorian algorithms produce identical > results. > > 3) Does PG want to fully follow the Gregorian Calendar rule? If so, > 4) do they want my one patch with two fixes6 This seems like it'd be more appropriate for pgsql-bugs or pgsql-hackers rather than here. I can't really figure out exactly what change you're proposing, so I'm not entirely sure whether it's right or wrong. Perhaps you could post your patch, and some examples. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Words missing in the following txt
--- On Wed, 12/29/10, Robert Haas wrote: > From: Robert Haas > Subject: Re: [DOCS] Words missing in the following txt > To: "Leslie S Satenstein" > Cc: [email protected] > Date: Wednesday, December 29, 2010, 6:45 AM > On Sun, Dec 26, 2010 at 8:28 PM, > Leslie S Satenstein > > wrote: > > In 8.1.1. Integer Types > > > > The ending sentence in the 2nd paragraph reads... > > > > The bigint type should only be used if the integer > range is insufficient, because the latter is definitely > faster. > > > > Integers are bigger or smaller, the sentence could > read better if phrased as follows: > > > > Use regular integers for fast efficient execution. The > bigint type should only be used if the integer range is > insufficient. > > The original phrasing might be a little too cute in the > sense that > "the latter" could be taken to refer to "the integer range" > rather > than "the integer data type", but the intended meaning is > pretty > obvious in context. I think your revised phrasing is > more negative > about bigints than we actually want to be. I think > bigints also > provide fast, efficient execution (compare with, say, > numeric) but > they are not AS fast as integers. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-docs mailing list ([email protected]) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-docs A good compromise is to perhaps consider the following. The bigint type should only be used if the integer range is insufficient, because calculation with the latter is definitely faster. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Some comments about Julian Dates and possible bug. Please provide feedback.
Good morning Robert I presume that you are the acting project manager, in the sense of vetting changes or commentary. The pdf guide has only one statement concerning julian dates. I feel that more is required. Julian dates are used as follows. Working days between two dates is (the difference of the day numbers * 5/7) , with minor adjustment for rounding and weekend start-end considerations. Julian date conversion is used for this type of calculation. It would be nice to see more in the manual about Julian dates, such as tests if a day is a weekend day, or to determine the day of the week for a specific Gregorian calendar date and vice-versa. Regarding the julian bug(let), I will raise it as a comment on the code buglist. -- Regards Leslie Mr. Leslie Satenstein mailto:[email protected] mailto [email protected] / [email protected] www.itbms.biz --- On Wed, 12/29/10, Robert Haas wrote: > From: Robert Haas > Subject: Re: [DOCS] Some comments about Julian Dates and possible bug. Please > provide feedback. > To: "Leslie S Satenstein" > Cc: "pgsql-docs" > Date: Wednesday, December 29, 2010, 6:58 AM > On Mon, Dec 27, 2010 at 9:23 PM, > Leslie S Satenstein > > wrote: > > I found the Julian date code that is programmed in > Postgres, to be accurate and fast except for one situation. > But, I do have one or two questions. 1) Which calendar is > being used? > > > > In the Gregorian Calendar, January 1, 0001 is lowest > positive date. > > The day before 1/1/0001, according to the Gregorian > calendar is December 31,-0001 in which the year has a value > of negative one --- there is no zero year in the Gregorian > Calendar. (zero year is an error) > > > > I tested and found the algorithm in Postgres to have > the day before January 1,0001 calculating as December > 31, even though the world calculates the day before > January 1,0001 as December 31,-0001. > > > > 2) Is the algorithm in Postgres correct? I think > not, as the calculations for the difference in days between > January 1, 0001 and December 31,-0001 is not 367 days, but > just the value 1. > > > > To convert the code to work with the Gregorian > calendar takes two fixes to two sub-routines. Each fix is > two lines of C code. > > > > I have tested the PG Date C language routines > with/without my fix, starting with the year around -4713 to > several centuries into the future. As long as both versions > calculate Julian dates that are later than 1/1/0001, both > the PG and my fixed versions respecting Gregorian algorithms > produce identical results. > > > > 3) Does PG want to fully follow the Gregorian Calendar > rule? If so, > > 4) do they want my one patch with two fixes6 > > This seems like it'd be more appropriate for pgsql-bugs or > pgsql-hackers rather than here. I can't really figure > out exactly > what change you're proposing, so I'm not entirely sure > whether it's > right or wrong. Perhaps you could post your patch, > and some examples. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- > Sent via pgsql-docs mailing list ([email protected]) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-docs > -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Words missing in the following txt
Leslie S Satenstein writes: > A good compromise is to perhaps consider the following. > The bigint type should only be used if the integer range is insufficient, > because calculation with the latter is definitely faster. This doesn't seem to me to fix the basic problem, which is that "the latter" appears to refer to "integer range". You don't calculate with ranges, but with types. Maybe it should be The bigint type should only be used if the range of the integer type is insufficient, because the latter is definitely faster. I'm not that excited about making the text specify that calculations are faster, because on most modern machines the actual calculation speed difference is pretty minuscule. What's expensive about bigint is pushing around twice as much data and/or having to do palloc's. regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Some comments about Julian Dates and possible bug. Please provide feedback.
Leslie S Satenstein writes: >> I tested and found the algorithm in Postgres to have >> the day before January 1,0001 calculating as December >> 31, even though the world calculates the day before >> January 1,0001 as December 31,-0001. > >> 2) Is the algorithm in Postgres correct? I think >> not, as the calculations for the difference in days between >> January 1, 0001 and December 31,-0001 is not 367 days, but >> just the value 1. This is not a bug, it's just failure to understand the conventions used internally. If you did the calculations at the SQL level you would get the right answers: regression=# select '0001-01-01'::date - 1; ?column? --- 0001-12-31 BC (1 row) regression=# select '0001-01-01'::date - '0001-12-31 BC'::date; ?column? -- 1 (1 row) Internally we represent 1 BC as "year zero", 2 BC as "year -1", etc, but this isn't a problem from users' perspective. regards, tom lane -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Words missing in the following txt
On Wed, Dec 29, 2010 at 12:46 PM, Tom Lane wrote: > Leslie S Satenstein writes: >> A good compromise is to perhaps consider the following. > >> The bigint type should only be used if the integer range is insufficient, >> because calculation with the latter is definitely faster. > > This doesn't seem to me to fix the basic problem, which is that "the > latter" appears to refer to "integer range". You don't calculate with > ranges, but with types. Maybe it should be > > The bigint type should only be used if the range of the integer > type is insufficient, because the latter is definitely faster. > > I'm not that excited about making the text specify that calculations are > faster, because on most modern machines the actual calculation speed > difference is pretty minuscule. What's expensive about bigint is > pushing around twice as much data and/or having to do palloc's. Yeah, I was actually wondering whether the first step here might be to benchmark this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
