Re: [HACKERS] Cost of XLogInsert CRC calculations

2005-03-06 Thread Heikki Linnakangas
On Sun, 6 Mar 2005, Tom Lane wrote: I suppose that the bulk of the CPU cycles being attributed to XLogInsert are going into the inlined CRC calculations. Maybe we need to think twice about the cost/benefit ratio of using 64-bit CRCs to protect xlog records that are often only a few dozen bytes.

Re: [HACKERS] Cost of XLogInsert CRC calculations

2005-03-06 Thread Simon Riggs
On Sun, 2005-03-06 at 00:17 -0500, Tom Lane wrote: I was profiling a case involving UPDATEs into a table with too many indexes (brought to mind by mysql's sql-bench, about which more later) and got this rather surprising result for routines costing more than 1% of the total runtime: Each

Re: [HACKERS] I am in Copenhagen

2005-03-06 Thread Kaare Rasmussen
I am in Copenhagen and am speaking tomorrow and will return on Sunday. I would have loved to hear your three hour speech about PostgreSQL administration, but unfortunately they put my own presentation at the exact same time, those LinuxForum 2005 bastards! -- Kaare Rasmussen

Re: [HACKERS] Missing coalesce

2005-03-06 Thread Robert Treat
On Sunday 06 March 2005 02:09, Jim C. Nasby wrote: ERROR: function coalence(interval, interval) does not exist I'm guessing this is an oversight, right? Where would I go about fixing it? If you've copy/pasted that error, then you need to s/coaleNce/coalesece so to speak. -- Robert Treat

Re: [HACKERS] refactoring fork() and EXEC_BACKEND

2005-03-06 Thread Magnus Hagander
This is a lot like what I was planning to work towards with the refactoring of the forkexec code I promised to do for 8.1. Cool. BTW, have we accepted that EXEC_BACKEND is the way we're going to workaround the lack of fork() on Win32 for the foreseeable future? I mean, it _works_, but it's

[HACKERS] Speeding up tupledesc copying

2005-03-06 Thread Tom Lane
I was just doing some profiling of plpgsql record operations, and noticed that an unreasonable amount of runtime was being consumed by palloc/pfree calls coming from CreateTupleDescCopy. The reason for this of course is that each attribute's storage is separately palloc'd. This seems a little

[HACKERS] Implementation of SQLCODE and SQLERRM variables for PL/pgSQL

2005-03-06 Thread Pavel Stehule
Hello This is my second patch, than please will be tolerant :-). For one my project I miss information about exception when I use EXCEPTION WITH OTHERS THEN. I found two Oracle's varaibles SQLCODE and SQLERRM which carry this information. With patch you can: -- -- Test of built variables

Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for PL/pgSQL

2005-03-06 Thread Tom Lane
Pavel Stehule [EMAIL PROTECTED] writes: This is my second patch, than please will be tolerant :-). For one my project I miss information about exception when I use EXCEPTION WITH OTHERS THEN. I found two Oracle's varaibles SQLCODE and SQLERRM which carry this information. I think we

Re: [HACKERS] Implementation of SQLCODE and SQLERRM variables for

2005-03-06 Thread Pavel Stehule
I think we discussed this last year and decided that it would be a bad idea to use those names because Oracle's use of them is not exactly compatible with our error codes and messages. SQLCODE in particular is not compatible at all --- it's an integer in Oracle, isn't it? There is more

[HACKERS] About b-tree usage

2005-03-06 Thread Ioannis Theoharis
Please let me know, if there is any option in postgresql to achieve the following usage of a b-tree index: For a relation R(att0, att1) and a btree index on attribute att0 In each insertion of a tuple on table: - look on index if the value of att0 of new entry does already exist in index,

Re: [HACKERS] About b-tree usage

2005-03-06 Thread Jeff Davis
If I understand your question, you want to reduce the index size by only pointing to the first tuple in a table with a given key in att0, since the rest of the tuples will be right afterward (because you keep the table clustered on that key). However, from the docs:

[HACKERS] ERROR: unrecognized node type in PostgresMain( )

2005-03-06 Thread mchron
Hi I'm implementing a new join that needs 2 hash tables, one for each relation. I declared a new type of node, DPHashJoin (with id T_DPHashJoin 121 at nodes.h) , which is by now the same as HashJoin plan node.I created a new plan with two Hash nodes, something that looks like a symmetric hash

Re: [HACKERS] Solving hash table overrun problems

2005-03-06 Thread Aaron Birkland
This also brings up a line of thought I had a while ago on a related topic. Something like a HashDistinct might be useful, if it had no startup cost. We already have that: the planner will use a HashAgg node in this fashion in some contexts (I think just as one of the ways to do IN,

Re: [HACKERS] ERROR: unrecognized node type in PostgresMain( )

2005-03-06 Thread Tom Lane
[EMAIL PROTECTED] writes: The problem is that while, Im running the postgres with gdb and I set a breakpoint at the function create_plan() of createplan.c, after some step commands,the gdb says that it cant recongnize the node 121 in the PostgresMain() function. That's not what gdb said at

Re: [HACKERS] buildfarm issues

2005-03-06 Thread Josh Berkus
Andrew, or 2.6.x ... in fact it's almost impossible to tell what might be installed on a Gentoo system, or how it was compiled. So I'm really not sure how we should treat such systems. Distribution, General OS, Kernel Version, Other Info e.g. SuSELinux 2.6.8-7 64-Bit MS