Re: PostgreSQL Anniversary Proposals -- Important

Started by Satoshi Nagayasualmost 20 years ago4 messages
#1Satoshi Nagayasu
nagayasus@nttdata.co.jp

Tom,

Luke Lonergan wrote:

I figure I can back it up...). What would people like to hear about?

How about future plans, so to speak? You've made some pretty significant
improvements for 8.1 (virtual tuples, the caching algorithm, etc), what's on
deck for 8.2 and beyond?

I'm *really* *really* interested in making PostgreSQL to be vacuum-less.
Can we have a vacuum-less PostgreSQL in the future? How?

If you have any ideas, I *really* want to hear about that from you.
It will be a next generation of PostgreSQL. :)

Thanks.
--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Satoshi Nagayasu (#1)

Satoshi Nagayasu <nagayasus@nttdata.co.jp> writes:

I'm *really* *really* interested in making PostgreSQL to be vacuum-less.
Can we have a vacuum-less PostgreSQL in the future? How?

I don't foresee that ever happening. AFAICS a non-vacuuming MVCC system
would have to be implemented just like Oracle (ie, rollback segments)
and as any Oracle DBA will tell you, that has plenty of drawbacks of
its own. Not to mention that Oracle probably has a few key patents
in that area.

Updating a database with transaction safety requires overhead, and
you're going to pay for that overhead somewhere. We've chosen to
pay for it via vacuum. I think that's a good system design in the
abstract --- for one thing, it keeps the overhead cost out of the
foreground transaction-processing code paths.

Of course we'll continue to whittle away at the problem of making
vacuum less objectionable --- autovacuum, reducing its i/o demand,
etc --- but I don't foresee us making a 180degree course correction
on such a fundamental design choice.

You can find plenty of discussion of this in past threads in the
pgsql-hackers archives.

regards, tom lane

#3Josh Berkus
josh@agliodbs.com
In reply to: Satoshi Nagayasu (#1)

Satoshi,

I'm *really* *really* interested in making PostgreSQL to be vacuum-less.
Can we have a vacuum-less PostgreSQL in the future? How?

I've heard a couple other requests for dealing with vaccuum. I think a
"Fixing Vacuum Round-Table" might be a valuable session if we have someone to
lead it. You ready?

To be clear: this is a meeting of PostgreSQL contributors. We can, and will,
have sessions which are problem-solving round tables and not one-way
presentations with slides.

Also, Tom, here's one which might be good: a "TODO" round-table led by you and
Bruce, where we talk about the todo list, the things that are likely to get
done, the things which aren't, what else should be on there, etc.

Another talk I'd like to see ... but I don't know who would give it ... would
be one on "Exotic PostgreSQL" which would survey Time Travel, TelegraphCQ,
Postgres-R, QBE, etc.

--
Josh Berkus
Aglio Database Solutions
San Francisco

#4Satoshi Nagayasu
nagayasus@nttdata.co.jp
In reply to: Josh Berkus (#3)

Josh,

Josh Berkus wrote:

I've heard a couple other requests for dealing with vaccuum. I think a
"Fixing Vacuum Round-Table" might be a valuable session if we have someone to
lead it. You ready?

If required. I want to know how people think about vacuum, and
many ideas around vacuum.

To be clear: this is a meeting of PostgreSQL contributors. We can, and will,
have sessions which are problem-solving round tables and not one-way
presentations with slides.

Cool.

Sure, it will be a good chance to discuss about the future direction
of PostgreSQL, and I'm very happy if I can join to many discussions.

Also, Tom, here's one which might be good: a "TODO" round-table led by you and
Bruce, where we talk about the todo list, the things that are likely to get
done, the things which aren't, what else should be on there, etc.

It's very interesting. I want this round-table to be an introduction
to the newbie hackers (like me).

--
NAGAYASU Satoshi <nagayasus@nttdata.co.jp>