Re: WIP: extensible enums - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WIP: extensible enums
Date
Msg-id AANLkTinUwb1pYtr437rNcc15b4cQx7nw7oQkPLy3LsAq@mail.gmail.com
Whole thread Raw
In response to Re: WIP: extensible enums  (David Fetter <david@fetter.org>)
List pgsql-hackers
On Wed, Oct 20, 2010 at 3:16 PM, David Fetter <david@fetter.org> wrote:
> On Tue, Oct 19, 2010 at 08:51:16PM -0400, Robert Haas wrote:
>> On Tue, Oct 19, 2010 at 5:42 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> > Well a bit more testing shows some benefit. I've sorted out a few kinks, so
>> > this seems to work. In particular, with the above tables, the version
>> > imported from 9.0 can create have an index created in about the same time as
>> > on the fresh table (identical data, but all even numbered Oids).
>> >
>> > Of course, with lots of odd numbered Oids, if a label gets added the
>> > imported version will degrade in performance much more quickly.
>>
>> I'm quite impressed by the amount of time and thought being put into
>> optimizing this.  I didn't realize people cared so much about enum
>> performance; but it's good that they do.
>>
>> I hope to see more such efforts in other parts of the system.
>
> Which parts of the system, in particular, do you have in mind?  Other
> people from EDB have mentioned that slimming down the on-disk
> representation was one such target.  What other ones would you see as
> needing such attention?

On-disk footprint.
WAL volume.
COPY speed.
Checkpoint I/O.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Creation of temporary tables on read-only standby servers
Next
From: Marti Raudsepp
Date:
Subject: Re: [PATCH] pgcrypto: Test for NULL before dereferencing pointer