Re: [PATCHES] Allow the identifier length to be increased via a
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Dhanaraj M wrote: I am sending the patch for the following TODO item: Allow the identifier length to be increased via a configure option You should use pg_config.h, not mangle postgres_ext.h like that. Or maybe generate postgres_ext.h from an hypotetical postgres_ext.h.in (but I wouldn't do that, really). I'm wondering how this got into the TODO list. It seems rather pointless, and likely to create client compatibility problems (if not, why is NAMEDATALEN exported at all?) Will this TODO item be removed from the list? Or I shall proceed with the suggestions given. Thanks Dhanaraj ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] pg_standby
On Thu, 2006-12-14 at 12:04 +, Simon Riggs wrote: pg_standby and test framework, in separate .tar files New version (v2), following further testing. Signal handling not included in this version. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com pg_standby.v2.tar Description: Unix tar archive ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Dead Space Map patch
On Thu, 2006-12-28 at 15:14 +0900, ITAGAKI Takahiro wrote: Even if it is off, DSM are always recorded and updated. The purpose of the patch, as I understand it, is performance. Can I ask what the performance overhead of this is for standard OLTP workloads? Do you have some performance numbers for VACUUM with/without this patch? Presumably it does speed things up considerably, but question is, how much? Is there a point where you VACUUM more than x% of a table that it is actually better to just VACUUM the whole thing, because of readahead? Is there a size of table for which keeps dsm information is not worthwhile? i.e. small tables -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [BUGS] BUG #2846: inconsistent and confusing
Tom Lane wrote: No, because you are still comparing against FLOAT4_MAX. I'm suggesting that only an actual infinity should be rejected. Even that is contrary to IEEE spec, though. The other problem with this coding technique is that it must invoke isinf three times when the typical case really only requires one (if the output isn't inf there is no need to perform isinf on the inputs). If we're going to check for overflow at all, I think we should lose the subroutine and just do if (isinf(result) !(isinf(arg1) || isinf(arg2))) ereport(...OVERFLOW...); I wasn't excited about doing one isinf() call to avoid three, so I just made a fast isinf() macro: /*We call isinf() a lot, so we use a fast version in this file */ #define fast_isinf(val) (((val) DBL_MIN || (val) DBL_MAX) isinf(val)) and used that instead of the direct isinf() call. (We do call fabs() in the Check* routines. Should we be using our own Abs()?) The new patch also uses float8 for float4 computations, and adds a comment about why (avoid underflow in some cases). In looking at the idea of checking for zero as an underflow, I found most transcendental functions already had such a check, so I moved the check into the Check*() routines, and added checks for multiplication/division underflow to zero. The only outstanding uncaught underflow is from addition/subtraction. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/backend/utils/adt/float.c === RCS file: /cvsroot/pgsql/src/backend/utils/adt/float.c,v retrieving revision 1.131 diff -c -c -r1.131 float.c *** src/backend/utils/adt/float.c 23 Dec 2006 02:13:24 - 1.131 --- src/backend/utils/adt/float.c 28 Dec 2006 20:32:32 - *** *** 87,92 --- 87,95 #define NAN (*(const double *) nan) #endif + /* We call isinf() a lot, so we use a fast version in this file */ + #define fast_isinf(val) (((val) DBL_MIN || (val) DBL_MAX) isinf(val)) + /* not sure what the following should be, but better to make it over-sufficient */ #define MAXFLOATWIDTH 64 #define MAXDOUBLEWIDTH 128 *** *** 104,111 int extra_float_digits = 0; /* Added to DBL_DIG or FLT_DIG */ ! static void CheckFloat4Val(double val); ! static void CheckFloat8Val(double val); static int float4_cmp_internal(float4 a, float4 b); static int float8_cmp_internal(float8 a, float8 b); --- 107,114 int extra_float_digits = 0; /* Added to DBL_DIG or FLT_DIG */ ! static void CheckFloat4Val(double val, bool has_inf_args, bool zero_is_valid); ! static void CheckFloat8Val(double val, bool has_inf_args, bool zero_is_valid); static int float4_cmp_internal(float4 a, float4 b); static int float8_cmp_internal(float8 a, float8 b); *** *** 211,219 * raise an ereport() error if it is */ static void ! CheckFloat4Val(double val) { ! if (fabs(val) FLOAT4_MAX) ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg(type \real\ value out of range: overflow))); --- 214,223 * raise an ereport() error if it is */ static void ! CheckFloat4Val(double val, bool has_inf_args, bool zero_is_valid) { ! /* If one of the input arguments was infinity, allow an infinite result */ ! if (fabs(val) FLOAT4_MAX (!fast_isinf(val) || !has_inf_args)) ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg(type \real\ value out of range: overflow))); *** *** 230,242 * raise an ereport() error if it is */ static void ! CheckFloat8Val(double val) { ! if (fabs(val) FLOAT8_MAX) ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg(type \double precision\ value out of range: overflow))); ! if (val != 0.0 fabs(val) FLOAT8_MIN) ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg(type \double precision\ value out of range: underflow))); --- 234,263 * raise an ereport() error if it is */ static void ! CheckFloat8Val(double val, bool has_inf_args, bool zero_is_valid) { ! /* ! * Computations that slightly exceed FLOAT8_MAX are non-Infinity, ! * but those that greatly exceed FLOAT8_MAX become Infinity. Therefore ! * it is difficult to tell if a value is really infinity or the result ! * of an overflow. The solution is to use a boolean indicating if ! * the input arguments were infiity, meaning an infinite result is ! * probably not the result of an overflow. This allows various ! * computations like SELECT 'Inf'::float8 + 5. ! */ ! if (fabs(val) FLOAT8_MAX (!fast_isinf(val) || !has_inf_args)) ereport(ERROR, (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE), errmsg(type \double precision\ value out of range: overflow))); ! /*
Re: [PATCHES] pg_standby
On Thu, 2006-12-28 at 19:26 +, Simon Riggs wrote: On Thu, 2006-12-14 at 12:04 +, Simon Riggs wrote: pg_standby and test framework, in separate .tar files New version (v2), following further testing. Signal handling not included in this version. Signal handling now added, tested and working correctly in version 3, attached. pg_standby is an example program for a warm standby script as discussed on -hackers: http://archives.postgresql.org/pgsql-hackers/2006-08/msg00407.php Program looks complete and ready for review, to me. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com pg_standby.v3.tar Description: Unix tar archive ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Tablespace for temporary objects and sort files
On 12/27/06, Albert Cervera Areny [EMAIL PROTECTED] wrote: Hi, here's a new version of the patch against HEAD with both, table and sort files working correctly for me. Regression tests work too. ok, i will test it a little ... what about temp tables created by SELECT INTO TEMP? look at src/backend/executor/execMain.c:OpenIntoRel() what about other temporary objects? I'd like to ask again the question I made on the first post as no answer was given at that time: The GetTempTablespace function correctly returns a different tablespace each time is called, but I store the position of the last tablespace used with an integer and iterate through the list of tablespaces each time. I tried to keep the iterator from call to call but I got a segfault, I imagine due to the memory context. Should I try to keep the iterator? How can I do it? i didn't read this last time, i will take a look at it now... when you post for the first time hackers where busy releasing 8.2.0, maybe they will pay more atention now :) -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [BUGS] BUG #2846: inconsistent and confusing
Bruce Momjian [EMAIL PROTECTED] writes: I wasn't excited about doing one isinf() call to avoid three, so I just made a fast isinf() macro: /*We call isinf() a lot, so we use a fast version in this file */ #define fast_isinf(val) (((val) DBL_MIN || (val) DBL_MAX) isinf(val)) This is *not* going in the right direction :-( regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] [BUGS] BUG #2846: inconsistent and
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I wasn't excited about doing one isinf() call to avoid three, so I just made a fast isinf() macro: /*We call isinf() a lot, so we use a fast version in this file */ #define fast_isinf(val) (((val) DBL_MIN || (val) DBL_MAX) isinf(val)) This is *not* going in the right direction :-( Well, then show me what direction you think is better. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster