Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-05-04 Thread Jim C. Nasby
On Thu, May 04, 2006 at 03:30:34PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > I'd actually been thinking about this recently, and had come up with the > > following half-baked ideas: > > > Allow a transaction to specify exactly what tables it will be touching, > > perh

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-05-04 Thread Florian G. Pflug
Tom Lane wrote: "Jim C. Nasby" <[EMAIL PROTECTED]> writes: I'd actually been thinking about this recently, and had come up with the following half-baked ideas: Allow a transaction to specify exactly what tables it will be touching, perhaps as an extension to BEGIN. Should any action that tra

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-05-04 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > I'd actually been thinking about this recently, and had come up with the > following half-baked ideas: > Allow a transaction to specify exactly what tables it will be touching, > perhaps as an extension to BEGIN. Should any action that transaction > tak

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-05-04 Thread Jim C. Nasby
On Sat, Apr 29, 2006 at 06:39:21PM -0400, Tom Lane wrote: > "Florian G. Pflug" <[EMAIL PROTECTED]> writes: > > The general problem seems to be that a transaction has no way to promise > > never to touch a specific table. Maybe some kind of "negative lock" > > would help here - you'd do "exclude t

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-05-02 Thread Csaba Nagy
> > I guess what I'm asking for is a kind of "REBUILD TABLE" which is not > > MVCC by definition but it would be useful in the mentioned queue table > > case. > > > > vaccum full ? Nope, it won't work, it will still leave in all the dead tuples potentially visible by old transactions, even if tho

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-29 Thread Tom Lane
"Florian G. Pflug" <[EMAIL PROTECTED]> writes: > The general problem seems to be that a transaction has no way to promise > never to touch a specific table. Maybe some kind of "negative lock" > would help here - you'd do "exclude table foo from transaction" at the > start of your transaction, whi

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-29 Thread Florian G. Pflug
Csaba Nagy wrote: There is, I believe, a problem there; there is a scenario where data can get "dropped out from under" those old connections. This has been added to the TODO... http://www.postgresql.org/docs/faqs.TODO.html * Make CLUSTER preserve recently-dead tuples per MVCC requirements O

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread Robert Treat
On Friday 28 April 2006 12:20, Csaba Nagy wrote: > > There is, I believe, a problem there; there is a scenario where data > > can get "dropped out from under" those old connections. > > > > This has been added to the TODO... > > > > http://www.postgresql.org/docs/faqs.TODO.html > > > > * Make CLUST

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread Csaba Nagy
> There is, I believe, a problem there; there is a scenario where data > can get "dropped out from under" those old connections. > > This has been added to the TODO... > > http://www.postgresql.org/docs/faqs.TODO.html > > * Make CLUSTER preserve recently-dead tuples per MVCC requirements OK, I

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread Chris Browne
[EMAIL PROTECTED] (Csaba Nagy) writes: > On Fri, 2006-04-28 at 15:20, kmh496 wrote: >> 2006-04-28 (금), 14:40 +0200, Csaba Nagy 쓰시길: >> > I placed a cron job to >> > cluster the queue table on it's PK index. >> what does that mean? > > Means execute: > > CLUSTER pk_queue_table ON queue_table

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread Csaba Nagy
> > actually does work, I can confirm that. Is it violating MVCC maybe ? > > Yes :-(. I think you can get away with it if all your transactions that [snip] Well, I actually don't want to get away this time :-) This table is only processed by the queue manager and that uses very short transactio

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread Tom Lane
Csaba Nagy <[EMAIL PROTECTED]> writes: > I'm not sure how this operation can work in the presence of other long > running transactions which did not touch the queue table yet, but it > actually does work, I can confirm that. Is it violating MVCC maybe ? Yes :-(. I think you can get away with it i

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread Vivek Khera
On Apr 28, 2006, at 9:32 AM, Csaba Nagy wrote: I'm not sure how this operation can work in the presence of other long running transactions which did not touch the queue table yet, but it actually does work, I can confirm that. Is it violating MVCC maybe ? It sounds like it does potentially vi

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread Csaba Nagy
On Fri, 2006-04-28 at 15:20, kmh496 wrote: > 2006-04-28 (금), 14:40 +0200, Csaba Nagy 쓰시길: > > I placed a cron job to > > cluster the queue table on it's PK index. > what does that mean? Means execute: CLUSTER pk_queue_table ON queue_table; See http://www.postgresql.org/docs/8.1/static/sql-cluste

Re: [GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread kmh496
2006-04-28 (금), 14:40 +0200, Csaba Nagy 쓰시길: > I placed a cron job to > cluster the queue table on it's PK index. what does that mean? -- my site http://www.myowndictionary.com";>myowndictionary was made to help students of many languages learn them faster. ---(end of

[GENERAL] Alternative for vacuuming queue-like tables

2006-04-28 Thread Csaba Nagy
Hi all, Short background: postgres does not support very well queue type tables in an environment where these queue tables are small in size but heavily inserted/updated/deleted, while there are activities in the system which cause long running transactions. The reason is that the queue table cann