Re: [HACKERS] Costs estimates for (inline SQL) functions ...

On Mon, 2006-08-21 at 07:31 +0200, Hans-Juergen Schoenig wrote: > CREATE OR REPLACE FUNCTION xy() RETURNS SETOF record AS $$ >SELECT relname::text, relpages::int4 >FROM pg_class; > $$ LANGUAGE SQL IMMUTABLE; > As far as i remember inlined SQL code has been implemented into

[HACKERS] Costs estimates for (inline SQL) functions ...

As my last mail did not seem to go through here one more try ... When looking at some fairly complex SQL stuff I came across some interesting issue which is a bit surprising to me: CREATE OR REPLACE FUNCTION xy() RETURNS SETOF record AS $$ SELECT relname::text, relpages::int4

Re: [HACKERS] PostgreSQL on 64 bit Linux

Josh, On 8/20/06 8:52 PM, "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > Is that true of even Woodcrest? > > Joshua D. Drake Not sure - haven't read anything about the register set on the Core 2 to make me think it benefits from 64 bit. The point may be academic from now on though - the compar

Re: [HACKERS] Replication

In contrast, the PostgreSQL team has chosen to provide hooks for replication and failover. This has led to a situation where there are multiple projects supporting replications/failover, none of which are production-ready nor shipped in a modern Linux distro. And no, we don't really provide

[HACKERS] Replication

One person who commented on the The business of Postbrsql made this comment: Posted Aug 3, 2006 8:45 UTC (Thu) by subscriber *jgarzik* [Link ]Cluster immaturity. MySQL has been shipping a workable single-master replication+failover for quite a while now in most

Re: [HACKERS] PostgreSQL on 64 bit Linux

WRT 64-bit and Postgres, it depends on the CPU as to whether you see a simple performance benefit. On the Opteron you will see a benefit when doing CPU bound work. When doing the CPU portion, the additional registers of the Opteron running in 64-bit mode are used by the compiler to produce a 2

Re: [HACKERS] PostgreSQL on 64 bit Linux

Naz, On 8/20/06 12:59 PM, "Naz Gassiep" <[EMAIL PROTECTED]> wrote: > I have a PostgreSQL installation on a Debian box that had the 64bit SMP > kernel installed before PostgreSQL was compiled and installed on it. > Does PostgreSQL take any advantage of the 64 bit environment or have we > not done

Re: [HACKERS] PostgreSQL on 64 bit Linux

[EMAIL PROTECTED] writes: > Is there an interest, or any active project to examine PostgreSQL in > the area of 64-bit processors? Has it already been done? I don't recall > seeing a reference to it in my travels. I'm also not sure on what to > expect for results, as the territory is still new. 64-

Re: [HACKERS] PostgreSQL on 64 bit Linux

On 8/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Is there an interest, or any active project to examine PostgreSQL in the area of 64-bit processors? Has it already been done? I don't recall seeing a reference to it in my travels. I'm also not sure on what to expect for results, as the te

Re: [HACKERS] PostgreSQL on 64 bit Linux

On Sun, Aug 20, 2006 at 04:46:30PM -0400, Douglas McNaught wrote: > Naz Gassiep <[EMAIL PROTECTED]> writes: > > I have a PostgreSQL installation on a Debian box that had the 64bit > > SMP kernel installed before PostgreSQL was compiled and installed on > > it. Does PostgreSQL take any advantage of

Re: [HACKERS] DROP OWNED BY doesn't work

I found one other problem in this area, which was that REASSIGN OWNED didn't work real well either after I changed serial sequences' dependency type to AUTO. What I did about it was to make shdepReassignOwned call ATExecChangeOwner with recursing = true, which suppresses all those tedious error ch

Re: [HACKERS] OTRS

All, > We use OTRS for customer issue tracking, but we use Jira from Atlassian > for our internal bug tracking. We also use Confluence and Fisheye from > Atlassian, and they are all excellent tools IMO. > > OTRS has been OK and fairly malleable. Actually, having done a fairly significant amount

Re: [HACKERS] [PATCHES] [PATCH] Provide 8-byte transaction IDs to

Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The part of this that would actually be useful to put in core is >> maintaining a 64-bit XID counter, ie, keep an additional counter that >> bumps every time XID wraps around. This cannot be done very well from >> outside core but it w

Re: [HACKERS] PostgreSQL on 64 bit Linux

Naz Gassiep <[EMAIL PROTECTED]> writes: > I just compiled as the manual says. I guess I must have compiled it > in 32. I'll recompile in 64 when I upgrade to 8.2 when it's out. The 'file' command will tell you whether a binary is 32- or 64-bit. If you have a full 64-bit install, you'll get a 64-

Re: [HACKERS] PostgreSQL on 64 bit Linux

Douglas McNaught wrote: Naz Gassiep <[EMAIL PROTECTED]> writes: I have a PostgreSQL installation on a Debian box that had the 64bit SMP kernel installed before PostgreSQL was compiled and installed on it. Does PostgreSQL take any advantage of the 64 bit environment or have we not

Re: [HACKERS] PostgreSQL on 64 bit Linux

Naz Gassiep <[EMAIL PROTECTED]> writes: > I have a PostgreSQL installation on a Debian box that had the 64bit > SMP kernel installed before PostgreSQL was compiled and installed on > it. Does PostgreSQL take any advantage of the 64 bit environment or > have we not done anything to move into the 64

[HACKERS] PostgreSQL on 64 bit Linux

I have a PostgreSQL installation on a Debian box that had the 64bit SMP kernel installed before PostgreSQL was compiled and installed on it. Does PostgreSQL take any advantage of the 64 bit environment or have we not done anything to move into the 64 bit world yet? Regards, - Naz -

Re: [HACKERS] pg_dump versus SERIAL, round N

Bruce Momjian <[EMAIL PROTECTED]> writes: > What method will people use to see if a sequence used as a default is > one that was created by SERIAL, and will be dropped by drop table, or > manually created? How does that distinction show up in pg_dump? BTW, it's easy to see if a column has an asso

Re: [HACKERS] pg_dump versus SERIAL, round N

Bruce Momjian <[EMAIL PROTECTED]> writes: > Also, if someone restores one table, does the sequence come with it like > it does now with SERIAL? Hm, probably not. I do have pg_dump set to force dumping of the sequence if you try to dump just its table, but it'd be possible to tell pg_restore (via

Re: [HACKERS] Windows 2000 Support

> > (btw, clinically insane without patching it.. And obviously > you didn't > > patch yours? :-P) > > Yeah, well it's behind all manner of firewalls, doing nothing > but buildfarm runs of which I ran the first before WSUS had > installed all the pending updates :-p Excuses, excuses... ;) //

Re: [HACKERS] Coverity reports looking good

On Sun, Aug 20, 2006 at 11:52:53AM -0400, Tom Lane wrote: > Martijn van Oosterhout writes: > > Whats basically left is a large number of memory leaks in frontend > > applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever > > really been a priority (buildACLCommands is really bad in

Re: [HACKERS] pg_dump versus SERIAL, round N

Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > What method will people use to see if a sequence used as a default is > > one that was created by SERIAL, and will be dropped by drop table, or > > manually created? How does that distinction show up in pg_dump? > > Hm. It will show

Re: [HACKERS] pg_dump versus SERIAL, round N

Tom Lane wrote: > Andreas Pflug <[EMAIL PROTECTED]> writes: > > I basically doubt the concept of a single owner. I'd expect a sequence > > to be dropped from cascaded table dropping, if that was the last usage > > and dependencies existed. This would probably mean "multiple owners". > > That's not

Re: [HACKERS] pg_dump versus SERIAL, round N

Bruce Momjian <[EMAIL PROTECTED]> writes: > What method will people use to see if a sequence used as a default is > one that was created by SERIAL, and will be dropped by drop table, or > manually created? How does that distinction show up in pg_dump? Hm. It will show in pg_dump because there wi

Re: [HACKERS] pg_dump versus SERIAL, round N

Andreas Pflug <[EMAIL PROTECTED]> writes: > I basically doubt the concept of a single owner. I'd expect a sequence > to be dropped from cascaded table dropping, if that was the last usage > and dependencies existed. This would probably mean "multiple owners". That's not going to happen without ext

Re: [HACKERS] Coverity reports looking good

On Sun, Aug 20, 2006 at 11:52:53AM -0400, Tom Lane wrote: > Well, if Coverity's idea of good programming practice is that every > program must explicitly free everything it ever malloced before it > terminates, then I'm afraid we'll have to agree to disagree. The I don't think Coverity even knows

Re: [HACKERS] pg_dump versus SERIAL, round N

Tom Lane wrote: > If you insist on initially creating the sequence by saying SERIAL for > the first of the tables, and then saying DEFAULT nextval('foo_seq') > for the rest, then under both 8.1 and my proposal you'd not be able to > drop the first table without dropping the sequence (thus requiring

Re: [HACKERS] default child of partition master

Keep in mind if you have multiple rules for a master table, it won't return the number of affected rows as you might expect. This screws up Hibernate which I'm using for my application. It checks the return value to make sure it was inserted properly. Luckily I only need one rule which puts it into

Re: [HACKERS] default child of partition master

"April Lorenzen" <[EMAIL PROTECTED]> writes: > My suggestion is to allow specifying a default destination table in > the master partition table definition. This default destination table > could be changed with ALTER TABLE. The recommended way to do this is with an ON INSERT DO INSTEAD rule on the

[HACKERS] default child of partition master

I'm using partitioned tables a lot and loving it. I have a suggestion that I believe would make it easier to bring the performance and maintenance advantages of partitions to more applications and users: As I understand it, at present I can select records from sales_master and get data returned f

Re: [HACKERS] Coverity reports looking good

Martijn van Oosterhout wrote: I thought I'd like to report that right now the Coverity reports are looking good. There are no issues detected in either the backend code or the ECPG library. For the latter I'd like the thank Joachim Wieland and Michael Meskes for getting ECPG into shape. Whats

Re: [HACKERS] Coverity reports looking good

Martijn van Oosterhout writes: > Whats basically left is a large number of memory leaks in frontend > applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever > really been a priority (buildACLCommands is really bad in this > respect). Well, if Coverity's idea of good programming pra

Re: [HACKERS] Coverity reports looking good

On Sun, Aug 20, 2006 at 03:49:24PM +0200, Martijn van Oosterhout wrote: > Whats basically left is a large number of memory leaks in frontend > applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever > really been a priority (buildACLCommands is really bad in this > respect). > ... > I

Re: [HACKERS] pg_dump versus SERIAL, round N

"Andrew Dunstan" <[EMAIL PROTECTED]> writes: > If we were implementing serial from scratch, I would be arguing that the > underlying sequence should be merely an implementation detail that should > be totally hidden, and sequences used explicitly should be kept as a > separate concept. Then many of

Re: [HACKERS] pg_dump versus SERIAL, round N

Andreas Pflug <[EMAIL PROTECTED]> writes: > As far as I understand your proposal I like it, but I'd like to insure > that the situation where a sequence is used by multiple tables is > handled correctly. There _are_ databases that reuse a sequence for > multiple serial-like columns, and pgadmin sup

[HACKERS] Coverity reports looking good

I thought I'd like to report that right now the Coverity reports are looking good. There are no issues detected in either the backend code or the ECPG library. For the latter I'd like the thank Joachim Wieland and Michael Meskes for getting ECPG into shape. Whats basically left is a large number o

Re: [HACKERS] pg_dump versus SERIAL, round N

Andreas Pflug wrote: > Tom Lane wrote: >> >> Almost everything I just said is already how it works today; the >> difference is that today you do not have the option to drop t1 without >> dropping the sequence, because there's no (non-hack) way to remove the >> dependency. >> > As far as I understan

Re: [HACKERS] pg_dump versus SERIAL, round N

Tom Lane wrote: > > Almost everything I just said is already how it works today; the > difference is that today you do not have the option to drop t1 without > dropping the sequence, because there's no (non-hack) way to remove the > dependency. > As far as I understand your proposal I like it, b

Re: [HACKERS] OTRS

> OTRS was recommended to me as a bug tracker. Has anyone used that? Nope, but looking at their demo i tseems they're actually *using* the HTML tag. Which probably should disqualify it out of hand ;-) That's just evil... //Magnus ---(end of broadcast)---

Re: [HACKERS] Bug with initDB under windows 2003

Hi Magnus,   Magnus Wrote: > I'd be interested in seeing the output from the command:> Subinacl /service NULL> > On a system where this does not work.>   Here is the output for "Subinacl /service NULL" Both, for the Administrator user and for the Postgres user:   Postgres user: >Subinacl /servic