An idle thought
in [PgSql]
|
From: Tom Lane on 16 Mar 2010 11:55 Greg Stark <stark(a)mit.edu> writes: > However then I started thinking about this case and wondered if it > wouldn't be possible to optimize. One of the suggested optimizations > was to look at using TRUNCATE. But I wonder why it's necessary to use > a dedicated command. Shouldn't it be possible for the system to notice > this situation and do effectively the same thing itself? Not unless you'd like DELETE to always acquire exclusive lock... > There are a couple problems with the way I've described this idea > here. Precisely because of the lack of lock. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 17 Mar 2010 16:44 On Tue, 2010-03-16 at 15:29 +0000, Greg Stark wrote: > big batch delete Is one of the reasons for partitioning, allowing the use of truncate. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 17 Mar 2010 17:09 On Tue, 2010-03-16 at 15:29 +0000, Greg Stark wrote: > I'm picturing storing a bit in the visibility map indicating that *no* > records are visible in a given page. I've been thinking for a while that we could store the visibility information in a structure separate from the heap -- sort of like the visibility map, but per-tuple and authoritative rather than a per-page hint. There are all kinds of challenges there, but it might be worth thinking about. Visibility information is highly compressible, and requires constant maintenance (updates, deletes, freezing, etc.). It also might make it possible to move to 64-bit xids, if we wanted to. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 17 Mar 2010 17:20 Jeff Davis <pgsql(a)j-davis.com> writes: > There are all kinds of challenges there, but it might be worth thinking > about. Visibility information is highly compressible, and requires > constant maintenance (updates, deletes, freezing, etc.). It also might > make it possible to move to 64-bit xids, if we wanted to. If you want it to be cheaply updatable (or even cheaply readable), compression is not what you're going to do. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 17 Mar 2010 17:39 On Wed, 2010-03-17 at 17:20 -0400, Tom Lane wrote: > Jeff Davis <pgsql(a)j-davis.com> writes: > > There are all kinds of challenges there, but it might be worth thinking > > about. Visibility information is highly compressible, and requires > > constant maintenance (updates, deletes, freezing, etc.). It also might > > make it possible to move to 64-bit xids, if we wanted to. > > If you want it to be cheaply updatable (or even cheaply readable), > compression is not what you're going to do. I didn't mean that we'd want to compress it to the absolute minimum size. I had envisioned that it would be a simple scheme designed only to eliminate long runs of identical visibility information (perhaps only the frozen and always visible regions would be compressed). The extra level of indirection would be slower, but if we freeze tuples more aggressively (which would be much cheaper if we didn't have to go to the heap), there might be a small number of tuples with interesting visibility information at any particular time. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 4 Prev: [HACKERS] An idle thought Next: parametrized NOTIFY - issue in plpgsql, maybe ToDo |