Re: [HACKERS] I am done

2002-09-03 Thread Bruce Momjian
Yes, I would like to know if it should be enabled by default, and whether we need a way to turn it off. I assume, considering the size of some of the queries, that we have to have a way to turn it off, and it is possible the admin may not want queries in the log, even if the generate errors. --

Re: [HACKERS] I am done

2002-09-03 Thread Gavin Sherry
Hi all, Does anyone else have an opinion on this? If not, I will implement it per Bruce's commentary. Gavin On Mon, 2 Sep 2002, Bruce Momjian wrote: > Gavin Sherry wrote: > > Okay, my bad. From my reading of the email exchange, I thought people > > wanted this on -- always. The best solution f

Re: [HACKERS] findoidjoins

2002-09-03 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://207.106.42.251/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Joe Conway wrote: > Tom Lane wrote: > > Alvaro H

Re: [HACKERS] findoidjoins

2002-09-03 Thread Joe Conway
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: >>Christopher Kings-Lynne dijo: >>>findoidjoins doens't seem to compile: >>Seems related to the ripping of libpgeasy out of the main >>distribution... > > I believe it's been broken for some time (disremember just why, maybe a > schema

Re: [HACKERS] webdav interface to pgsql

2002-09-03 Thread Christopher Kings-Lynne
Cool. Is it worth putting it on greatbridge? gborg.postgresql.org With the new tightening of the postgres source tree, it's unlikely this would make it into our CVS methinks, however people are working on setting up greatbridge as a one-stop-shop for postgres add-ons... Chris > -Original

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Mario Weilguni
Am Mittwoch, 4. September 2002 05:44 schrieb Matthew T. OConnor: > I have been doing some poking around with this item, and I was planning on > using the stats collector to do "intelligent" auto-vacuuming. I was > planning on adding some new columns that account for activity that has > taken plac

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Matthew T. OConnor
On Tuesday 03 September 2002 23:47, Christopher Kings-Lynne wrote: > > I have been doing some poking around with this item, and I was > > planning on > > using the stats collector to do "intelligent" auto-vacuuming. I > > was planning > > on adding some new columns that account for activity that

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Christopher Kings-Lynne
> I have been doing some poking around with this item, and I was > planning on > using the stats collector to do "intelligent" auto-vacuuming. I > was planning > on adding some new columns that account for activity that has taken place > since the last vacuum. The current stats collector sh

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Matthew T. OConnor
On Tuesday 03 September 2002 16:24, Tom Lane wrote: > "Mario Weilguni" <[EMAIL PROTECTED]> writes: > > That brings me to another point, can't the > > statistics collector used for that? > > Hmm, that would be a different way of attacking the problem. Not sure > offhand which is better, but it'd s

Re: [HACKERS] FW: [GWAVA:fku1fb18] Source block message notification

2002-09-03 Thread Bruce Momjian
Yes, we have told Marc to remove it several times. He may be having trouble figuring out which email address is generating it. --- Christopher Kings-Lynne wrote: > Does anyone else get this rubbish when they post to -php ?

[HACKERS] FW: [GWAVA:fku1fb18] Source block message notification

2002-09-03 Thread Christopher Kings-Lynne
Does anyone else get this rubbish when they post to -php ? Our domain isn't on any blacklists AFAIK... Chris > -Original Message- > From: GWAVA [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 4 September 2002 11:24 AM > To: [EMAIL PROTECTED] > Subject: [GWAVA:fku1fb18] Source block messag

[HACKERS] webdav interface to pgsql

2002-09-03 Thread joel w. reed
i've hacked out a webdav (apache2) interface to pgsql. i'd love to replicate the browsing/managing interfaces of the bigname RDBMS's using webdav for pgsql but i'm not sure how far i'll get. right now the 0.1.15 release supports a fair number of browsing options (tables, columns, functions, sequen

Re: [HACKERS] I am done

2002-09-03 Thread Alexandre Dulaunoy
On Tue, 3 Sep 2002, Kaare Rasmussen wrote: > > Are you guys competing for the modesty award? ;-) > > I heard Stallman is trying to win it this year. :-) > > Hah, that's a good one. > > For doing what - telling you not to call it GNU/Linux, only Linux/GNU ? > :-) SELECT FreeProject FROM His

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Christopher Kings-Lynne
> That brings me to another point, is there interest for this > web-statistics-frontend, maybe for /contrib? I found it extremly useful > because it showed up the weak points in my applications. Why not create a project here for it: http://gborg.postgresql.org/ Chris -

Re: [HACKERS] source code indexer

2002-09-03 Thread Laurette Cisneros
Thanks to everyone who made suggestions. I have found Source Navigator to be very close and useful for what I was looking for! Thanks again, L. On Fri, 30 Aug 2002, Manfred Koizar wrote: > On Fri, 30 Aug 2002 11:57:17 -0700 (PDT), Laurette Cisneros > <[EMAIL PROTECTED]> wrote: > >I was won

Re: [HACKERS] 7.2.2 bug?

2002-09-03 Thread Tom Lane
Rod Taylor <[EMAIL PROTECTED]> writes: > Took me a while, but I eventually figured out that they changed the > NAMEDATALEN in the old version, and didn't match it in the new one. Grumble. It occured to us to store NAMEDATALEN in pg_control in 7.3, but 7.2 doesn't have that defense. Sorry bout t

Re: [HACKERS] 7.2.2 bug?

2002-09-03 Thread Rod Taylor
On Tue, 2002-09-03 at 16:42, Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > DEBUG: server process (pid 9097) was terminated by signal 10 > > Could we have a backtrace from that core dump? > > AFAICT it's getting through the WAL redo just fine, so the problem > is (probably) not wh

Re: [HACKERS] 7.2.2 bug?

2002-09-03 Thread Tom Lane
Rod Taylor <[EMAIL PROTECTED]> writes: > DEBUG: server process (pid 9097) was terminated by signal 10 Could we have a backtrace from that core dump? AFAICT it's getting through the WAL redo just fine, so the problem is (probably) not what you think. regards, tom lane -

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Tom Lane
"Mario Weilguni" <[EMAIL PROTECTED]> writes: > That brings me to another point, can't the > statistics collector used for that? Hmm, that would be a different way of attacking the problem. Not sure offhand which is better, but it'd surely be worth considering both. Note that collecting of dead-

Re: [HACKERS] CREATE CAST requires immutable cast function?

2002-09-03 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I'm not wedded to it, I just modelled it after the SQL standard, but > evidently the volatility levels are different in detail. I would disallow > volatile casts in any case. There ought to be a minimal behavioral > contract between creators and use

Re: [HACKERS] Docs for v7.3 ...

2002-09-03 Thread Bruce Momjian
Peter Eisentraut wrote: > Marc G. Fournier writes: > > > Just a quick one before I package up the wrong thing ... where should I be > > pulling docs from? :) > > cd doc/src > gmake postgres.tar.gz > > You can take the man pages from an old release until we figure them out. Woh. Better to ship

Re: [HACKERS] CREATE CAST requires immutable cast function?

2002-09-03 Thread Peter Eisentraut
Tom Lane writes: > Perhaps there's a case for prohibiting volatile casts (as opposed to > stable ones), but I don't really see it. I'd prefer to just remove > this restriction. Comments? I'm not wedded to it, I just modelled it after the SQL standard, but evidently the volatility levels are di

Re: [HACKERS] Memory management question

2002-09-03 Thread Joe Conway
Nigel J. Andrews wrote: > > It's probably a pretty basic question explained in some document I haven't seen > but...if I do something like a CreateTupleDescCopy() how do I know my memory > context owns everything allocated without following the code all the way > through until it returns to me?

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Barry Lind
Wouldn't it make sense to implement autovacuum information in a struture like the FSM, a Dirty Space Map (DSM)? As blocks are dirtied by transactions they can be added to the DSM. Then vacuum can give priority processing to those blocks only. The reason I suggest this is that in many usage

[HACKERS] 7.2.2 bug?

2002-09-03 Thread Rod Taylor
Seems it wants to run a redo entry that doesn't exist. Not a big deal as it's a test environment only. It was recently upgraded from 7.2.1 to 7.2.2. I'm wondering whether the person who did the upgrade shutdown the daemon before installing. FATAL 1: The database system is starting up FATAL

Re: [HACKERS] I am done

2002-09-03 Thread Alexandre Dulaunoy
On Tue, 3 Sep 2002, Kaare Rasmussen wrote: > > Are you guys competing for the modesty award? ;-) > > I heard Stallman is trying to win it this year. :-) > > Hah, that's a good one. > > For doing what - telling you not to call it GNU/Linux, only Linux/GNU ? > :-) SELECT FreeProject FROM His

Re: [HACKERS] Wanted: pgdiff ($$$)

2002-09-03 Thread Justin Clift
Hi all, Just a link to this from the front page of the techdocs.postgresql.org site. Hope it helps. :-) Regards and best wishes, Justin Clift Greg Stark wrote: > > [EMAIL PROTECTED] (ad wolf) writes: > > > We're offering a small reward for a PG hacker that can code up a > > mysqldiff-like

Re: [HACKERS] Docs for v7.3 ...

2002-09-03 Thread Peter Eisentraut
Marc G. Fournier writes: > Just a quick one before I package up the wrong thing ... where should I be > pulling docs from? :) cd doc/src gmake postgres.tar.gz You can take the man pages from an old release until we figure them out. (Any news on repackaging 7.2.2?) -- Peter Eisentraut [EMAI

Re: [HACKERS] I am done

2002-09-03 Thread Kaare Rasmussen
> Are you guys competing for the modesty award? ;-) > I heard Stallman is trying to win it this year. :-) Hah, that's a good one. For doing what - telling you not to call it GNU/Linux, only Linux/GNU ? :-) -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Data

Re: [HACKERS] Wanted: pgdiff ($$$)

2002-09-03 Thread Kaare Rasmussen
> You might want to check out the perl model Alzabo, I think it's capable of > doing this. It does not (yet) support foreign keys, alas. But if anybody likes to code this, maybe they could work together with the Alzabo developer. -- Kaare Rasmussen--Linux, spil,--Tlf:

Re: [HACKERS] Inheritance

2002-09-03 Thread Bruce Momjian
Peter Gulutzan wrote: > The August draft of the SQL:200n standard (9075-2 Foundation) says in > Section 4.17.2: "Every table constraint specified for base table T is > implicitly a constraint on every subtable of T, by virtue of the fact > that every row in a subtable is considered to have a corre

Re: [HACKERS] Wanted: pgdiff ($$$)

2002-09-03 Thread Greg Stark
[EMAIL PROTECTED] (ad wolf) writes: > We're offering a small reward for a PG hacker that can code up a > mysqldiff-like utility for PG. For those unfamiliar with mysqldiff: > http://adamspiers.org/computing/mysqldiff/ You might want to check out the perl model Alzabo, I think it's capable of d

Re: [HACKERS] Just testing tighgter UCE controls ...

2002-09-03 Thread Marc G. Fournier
On Tue, 3 Sep 2002, Vince Vielhaber wrote: > On Tue, 3 Sep 2002, Marc G. Fournier wrote: > > > > > ignore if you see this ... > > What if we don't see it? let me know? :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http:

Re: [HACKERS] serial type as foreign key referential integrity

2002-09-03 Thread Stephan Szabo
On 31 Aug 2002, Zhicong Leo Liang wrote: > Hi all, > Just briefly describe my problem. > I have two tables. > create table A( >a1 serial primary key, >a2 varchars(10) > ); > create table B( > b1 integer primary key, > b2 Integer, > foreign key(b2) references a(a1)

Re: [HACKERS] BYTEA with ecpg

2002-09-03 Thread Michael Meskes
On Tue, Aug 27, 2002 at 05:59:36AM +, Mike Sacauskis wrote: > How do I do an insert and retreival for bytea field using embedded SQL? > Anybody have a code example? I'm trying to port from informix to > postgresQL. Actually I never tried. Doesn't it work with using an array of char as C va

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Mario Weilguni
>I do not think we need or want a control table for this; certainly I see >no need for per-table manual control over this process. There should >probably be a few knobs in the form of GUC parameters so that the admin >can control how much overall work the auto-vacuumer does. For instance >you'd

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Tom Lane
Rod Taylor <[EMAIL PROTECTED]> writes: > On Tue, 2002-09-03 at 11:01, Tom Lane wrote: >> For vacuum's purposes all that we really care to know about is the >> number of obsoleted tuples in each table: committed deletes and updates, >> and aborted inserts and updates all count. Furthermore, we do

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Rod Taylor
On Tue, 2002-09-03 at 11:01, Tom Lane wrote: > "Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > > 1)Is this sounds like a workable solution? > > Adding a trigger to every tuple update won't do at all. Storing the > counts in a table won't do either, as the updates on that table will > generat

Re: [HACKERS] Memory management question

2002-09-03 Thread Serguei A. Mokhov
Maybe when this thread is over, some parts of it can be added to the dev. FAQ? -s On Tue, 3 Sep 2002, Karel Zak wrote: > Date: Tue, 3 Sep 2002 13:52:09 +0200 > From: Karel Zak <[EMAIL PROTECTED]> > To: Nigel J. Andrews <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] Memory

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Tom Lane
"Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > 1)Is this sounds like a workable solution? Adding a trigger to every tuple update won't do at all. Storing the counts in a table won't do either, as the updates on that table will generate a huge amount of wasted space themselves (not to mentio

Re: [HACKERS] Just testing tighgter UCE controls ...

2002-09-03 Thread Vince Vielhaber
On Tue, 3 Sep 2002, Marc G. Fournier wrote: > > ignore if you see this ... What if we don't see it? Vince. -- == Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net 56K Nationwide Dialup f

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Shridhar Daithankar
On 3 Sep 2002 at 9:49, Tom Lane wrote: > In terms of what might happen for 7.4 or beyond, what I'd personally > like to see is some "auto vacuum" facility that would launch background > vacuums automatically every so often. This could (eventually) be made > self-tuning so that it would vacuum he

[HACKERS] contrib/cube update

2002-09-03 Thread Bruno Wolff III
What I changed is covered in the CHANGES file. Note that this includes a bug fix I already subimtted. These changes are versus 7.3 CVS and may not be backwards compatible with 7.2. They do not include a bug fix for a problem I reported with cube_yyerror. A context diff is attached. diff -c -r -N

[HACKERS] Inquiry From Form [pgsql]

2002-09-03 Thread control
does anybody know who i can talk to about a virus/bug scanning engine for postgresql tables/webportal stuff? i would like to start a proof-of-concept thread for this. sounds strange, i know, but chill out, details to come. ---(end of broadcast)--

[HACKERS] Sprintf() auditing and a patch

2002-09-03 Thread Jukka Holappa
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm very new to this project and inspired by recent security release, I started to audit postgresql source against common mistakes with sprintf(). I mostly found problems with sprintf() used on statically allocated buffers or dynamically allocat

Re: [HACKERS] Inheritance

2002-09-03 Thread Peter Gulutzan
The August draft of the SQL:200n standard (9075-2 Foundation) says in Section 4.17.2: "Every table constraint specified for base table T is implicitly a constraint on every subtable of T, by virtue of the fact that every row in a subtable is considered to have a corresponding superrow in every one

[HACKERS] BYTEA with ecpg

2002-09-03 Thread Mike Sacauskis
How do I do an insert and retreival for bytea field using embedded SQL? Anybody have a code example? I'm trying to port from informix to postgresQL. Thanks Mike ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archiv

[HACKERS] Just testing tighgter UCE controls ...

2002-09-03 Thread Marc G. Fournier
ignore if you see this ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] serial type as foreign key referential integrity violation

2002-09-03 Thread Shridhar Daithankar
On 31 Aug 2002 at 5:28, Zhicong Leo Liang wrote: > Hi all, > Just briefly describe my problem. > I have two tables. > create table A( >a1 serial primary key, >a2 varchars(10) that should be varchar.. > ); > create table B( > b1 integer primary key, > b2 Integer, >

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Tom Lane
Mario Weilguni <[EMAIL PROTECTED]> writes: > I know everyone is busy with the 7.3beta, but maybe this is something > to think of before releasing the beta. We are already in feature freeze. In terms of what might happen for 7.4 or beyond, what I'd personally like to see is some "auto vacuum" fac

Re: [HACKERS] Memory management question

2002-09-03 Thread Tom Lane
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > It's probably a pretty basic question explained in some document I > haven't seen but...if I do something like a CreateTupleDescCopy() how > do I know my memory context owns everything allocated without > following the code all the way through until

Re: [HACKERS] findoidjoins

2002-09-03 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Christopher Kings-Lynne dijo: >> findoidjoins doens't seem to compile: > Seems related to the ripping of libpgeasy out of the main > distribution... I believe it's been broken for some time (disremember just why, maybe a schema issue?). I had a TODO

Re: [HACKERS] [INTERFACES] pgaccess 0.98.8 beta 1 - the show starts

2002-09-03 Thread Teo
- Original Message - From: "Iavor Raytchev" <[EMAIL PROTECTED]> To: "pgaccess - developers" <[EMAIL PROTECTED]>; "pgaccess - users" <[EMAIL PROTECTED]>; "pgsql-interfaces" <[EMAIL PROTECTED]>; "pgsql-hackers" <[EMAIL PROTECTED]> Sent: Saturday, August 31, 2002 8:55 PM Subject: [INTERFACES]

[HACKERS] new index access methods

2002-09-03 Thread HÃ¥kon Hagen Clausen
Hi, I'm planning to experiment with a new index access method. More specifically I want to plug an external index program in to postgres as an index. Does anybody have some hints on how I can find some info on where to begin? I have looked a little bit on the GIST project, and in the programmers

Re: [HACKERS] contrib/ intarray, ltree, intagg broken(?) by array

2002-09-03 Thread mlw
This built and worked on my system. famous last words, huh? Bruce Momjian wrote: > > Can someone address the intagg issue here, or is the code OK? > > --- > > Tom Lane wrote: > > Joe Conway and I have just committed some

[HACKERS] Wanted: pgdiff ($$$)

2002-09-03 Thread ad wolf
We're offering a small reward for a PG hacker that can code up a mysqldiff-like utility for PG. For those unfamiliar with mysqldiff: http://adamspiers.org/computing/mysqldiff/ Creating something similar for PG is slightly more involved (because of the ref. integrity issues, among others...), bu

[HACKERS] serial type as foreign key referential integrity violation

2002-09-03 Thread Zhicong Leo Liang
Hi all, Just briefly describe my problem. I have two tables. create table A( a1 serial primary key, a2 varchars(10) ); create table B( b1 integer primary key, b2 Integer, foreign key(b2) references a(a1) ) insert into A values('123'); select a1 from A where a2='123'

Re: [HACKERS] 7.3 gotchas for applications and client libraries

2002-09-03 Thread Tom Lane
Lee Kindness <[EMAIL PROTECTED]> writes: > CREATE OR REPLACE FUNCTION column_exists(NAME, NAME) RETURNS BOOLEAN AS ' > CREATE OR REPLACE FUNCTION table_exists(NAME) RETURNS BOOLEAN AS ' > Obviously these need attention when our application targets 7.3 (and > thanks for the heads-up), but all c

Re: [HACKERS] Memory management question

2002-09-03 Thread Nigel J. Andrews
On Tue, 3 Sep 2002, Karel Zak wrote: > On Tue, Sep 03, 2002 at 12:28:37PM +0100, Nigel J. Andrews wrote: > > > > > > It's probably a pretty basic question explained in some document I haven't seen > > but...if I do something like a CreateTupleDescCopy() how do I know my memory > > context owns

Re: [HACKERS] HISTORY file

2002-09-03 Thread Marc G. Fournier
On Tue, 3 Sep 2002, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Yes, I haven't gotten to the release checklist yet. Let's delay a day. > > Or at least late in the day tomorrow. I have some loose ends to clean > up yet as well, but I'm beat and am going to bed. > > But I assu

Re: [HACKERS] HISTORY file

2002-09-03 Thread Marc G. Fournier
S'alright, I can do the package together tomorrow morning to let you wrap up the loose ends :) On Tue, 3 Sep 2002, Bruce Momjian wrote: > I am still working on the 7.3 HISTORY file. I have extracted the items, > but I have to worksmith them and write an introduction. > > It is midnight here no

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Rod Taylor
On Tue, 2002-09-03 at 03:36, Mario Weilguni wrote: > > gets updated for each transaction but log table is just an insert. So > rather > > than vacumming entire db, just doing 'vacuum analyze accounts' give me > almost > > same results. > > > > That is not really practicable, one datebase has 107

Re: [HACKERS] Memory management question

2002-09-03 Thread Karel Zak
On Tue, Sep 03, 2002 at 12:28:37PM +0100, Nigel J. Andrews wrote: > > > It's probably a pretty basic question explained in some document I haven't seen > but...if I do something like a CreateTupleDescCopy() how do I know my memory > context owns everything allocated without following the code al

Re: [HACKERS] Memory management question

2002-09-03 Thread Gavin Sherry
On Tue, 3 Sep 2002, Nigel J. Andrews wrote: > > > It's probably a pretty basic question explained in some document I haven't seen > but...if I do something like a CreateTupleDescCopy() how do I know my memory > context owns everything allocated without following the code all the way > through u

[HACKERS] Memory management question

2002-09-03 Thread Nigel J. Andrews
It's probably a pretty basic question explained in some document I haven't seen but...if I do something like a CreateTupleDescCopy() how do I know my memory context owns everything allocated without following the code all the way through until it returns to me? -- Nigel J. Andrews -

[HACKERS] 7.3 gotchas for applications and client libraries

2002-09-03 Thread Lee Kindness
Tom, do you think there is millage in adding functions (at least to contrib) to PostgreSQL to avoid some of the common tasks applications look into pg_* for? For example I recently audited our code here for pg_* access, and managed to create two plpgsql functions to replace all occurrences. They

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Shridhar Daithankar
On 3 Sep 2002 at 15:39, Christopher Kings-Lynne wrote: > > Actually that's what I did. Update global transaction counter > > than trigger the > > vacuum from a spare thread. > > > > but having it in DB has advantages of centralisation. It's just a > > good to have > > kind of thing.. > > Care t

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Shridhar Daithankar
On 3 Sep 2002 at 9:36, Mario Weilguni wrote: > That is not really practicable, one datebase has 107 tables, and making a > cron job > with 107 vacuum calls is completly out of question and very error prone > anyway. That's correct.. What are the possible alternatives? Either backend has to suppo

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Christopher Kings-Lynne
> Actually that's what I did. Update global transaction counter > than trigger the > vacuum from a spare thread. > > but having it in DB has advantages of centralisation. It's just a > good to have > kind of thing.. Care to submit it as a BSD licensed contrib module then? Or at least create a p

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Mario Weilguni
> gets updated for each transaction but log table is just an insert. So rather > than vacumming entire db, just doing 'vacuum analyze accounts' give me almost > same results. > That is not really practicable, one datebase has 107 tables, and making a cron job with 107 vacuum calls is completly ou

Re: [HACKERS] possible vacuum improvement?

2002-09-03 Thread Shridhar Daithankar
On 3 Sep 2002 at 15:14, Christopher Kings-Lynne wrote: > > Personally I would prefer to have a trigger on a metadata table > > where I could > > trigger vacuuming a particular table each n number of > > transactions(Oh it would > > be great if that vacuum runs in background not blocking meta data