Re: [GENERAL] Chunk Delete

2007-11-18 Thread Csaba Nagy
On Thu, 2007-11-15 at 17:13 +, Gregory Stark wrote: > DELETE > FROM atable AS x > USING (SELECT ctid FROM atable LIMIT 5) AS y > WHERE x.ctid = y.ctid; Have you tried to EXPLAIN this one ? Last time I tried to do something similar it was going for a sequential scan on atable with a fi

Re: [GENERAL] Chunk Delete

2007-11-17 Thread Gregory Stark
"Abraham, Danny" <[EMAIL PROTECTED]> writes: > Hi, > > I am wondering if I can do in PG Chunck Delete, like the Oracle example > below. > > In Oracle we erase 50,000 records using the following: > > Delete where and ROWNUM < 5; > > Do we have such a feature in PG? You can still use a subqu

Re: [GENERAL] Chunk Delete

2007-11-17 Thread Csaba Nagy
[snip] > With Oracle we do it with: delete ,tname> where and rownum < > Y; > Can we have the same goody on Postgres? The attached message is Tom's response to a similar question, in any case it would work fine in your case too (assuming you have postgres 8.2). HTH, Csaba. --- Begin Message -

Re: [GENERAL] Chunk Delete

2007-11-16 Thread Abraham, Danny
Say we have a FIFO of 800,000,000 records. No primary key is required - this is only audit information. We do not use it on Oracle too. Based on a condition, 2,000,000 records should be deleted daily. We have a background process that wakes up every X minutes and deletes Y records.

Re: [GENERAL] Chunk Delete

2007-11-15 Thread Sam Mason
On Thu, Nov 15, 2007 at 02:46:09PM +0100, Alexander Staubo wrote: > On 11/15/07, Abraham, Danny <[EMAIL PROTECTED]> wrote: > > With Oracle we do it with: delete ,tname> where and rownum < Y; > > You could create a temporary sequence: > > create temporary sequence foo_seq; > delete from fo

Re: [GENERAL] Chunk Delete

2007-11-15 Thread Andrew Sullivan
On Thu, Nov 15, 2007 at 03:09:10PM +0200, Abraham, Danny wrote: > THE problem is that the table does not have a primary key; Too > expensive. If the table doesn't have a primary key, you've designed it wrong. But I'd like to see any evidence you have at all that having a primary key is "too expen

Re: [GENERAL] Chunk Delete

2007-11-15 Thread Abraham, Danny
The temporary sequence works perfectly for me. Thanks ---(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: [GENERAL] Chunk Delete

2007-11-15 Thread Alexander Staubo
On 11/15/07, Abraham, Danny <[EMAIL PROTECTED]> wrote: > In Oracle we erase 50,000 records using the following: > > Delete where and ROWNUM < 5; > > Do we have such a feature in PG? Just delete with a subselect: delete from where in ( select from order by limit 5); For examp

Re: [GENERAL] Chunk Delete

2007-11-15 Thread Sam Mason
On Thu, Nov 15, 2007 at 09:43:52AM -0500, Andrew Sullivan wrote: > On Thu, Nov 15, 2007 at 03:33:04PM +0200, Abraham, Danny wrote: > > > > Based on a condition, 2,000,000 records should be deleted daily. > > Why not use that condition (which I presume is indexed) as the criterion for > your dele

Re: [GENERAL] Chunk Delete

2007-11-15 Thread Andrew Sullivan
On Thu, Nov 15, 2007 at 03:33:04PM +0200, Abraham, Danny wrote: > > Based on a condition, 2,000,000 records should be deleted daily. Why not use that condition (which I presume is indexed) as the criterion for your delete? I mean, how else are you getting those row numbers in Oracle. They have

Re: [GENERAL] Chunk Delete

2007-11-15 Thread Sam Mason
On Thu, Nov 15, 2007 at 04:18:27PM +0200, Abraham, Danny wrote: > The temporary sequence works perfectly for me. You may want to read my other message and test again. You are well into implementation details here and the trick that was suggested will (with the current version of PG delete the fir

Re: [GENERAL] Chunk Delete

2007-11-15 Thread Alexander Staubo
On 11/15/07, Abraham, Danny <[EMAIL PROTECTED]> wrote: > With Oracle we do it with: delete ,tname> where and rownum < Y; You could create a temporary sequence: create temporary sequence foo_seq; delete from foos where nextval('foo_seq') < 5; I'm not sure how fast nextval() is, even o