Re: [PERFORMANCE] slow small delete on large table
От | Ed L. |
---|---|
Тема | Re: [PERFORMANCE] slow small delete on large table |
Дата | |
Msg-id | 200402241136.08556.pgsql@bluepolka.net обсуждение исходный текст |
Ответ на | Re: [PERFORMANCE] slow small delete on large table (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On Monday February 23 2004 10:23, Tom Lane wrote: > "Ed L." <pgsql@bluepolka.net> writes: > > If I could say it the way I think for a simple example, it'd be > > like this: > > > > delete from mytable > > where posteddatetime < now() - '90 days' > > limit 100; > > > > Of course, that's not legal 7.3.4 syntax. > > Assuming you have a primary key on the table, consider this: > > CREATE TEMP TABLE doomed AS > SELECT key FROM mytable WHERE posteddatetime < now() - '90 days' > LIMIT 100; > > DELETE FROM mytable WHERE key = doomed.key; > > DROP TABLE doomed; > > Depending on the size of mytable, you might need an "ANALYZE doomed" > in there, but I'm suspecting not. A quick experiment suggests that > you'll get a plan with an inner indexscan on mytable.key, which is > exactly what you need. I didn't mention I'd written a trigger to do delete N rows on each new insert (with a delay governor preventing deletion avalanches). The approach looks a little heavy to be done from within a trigger with the response time I need, but I'll try it. Cantchajust toss in that "limit N" functionality to delete clauses? How hard could that be? ;) > See also Chris Browne's excellent suggestions nearby, if you are willing > to make larger readjustments in your thinking... I did a search for articles by Chris Browne, didn't see one that appeared relevant. What is the thread subject to which you refer?
В списке pgsql-performance по дате отправления: