Re: [HACKERS] 8.2 features?

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Christopher Kings-Lynne <chris(dot)kings-lynne(at)calorieking(dot)com>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bernd Helmle <mailings(at)oopsware(dot)de>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Susanne Ebrecht <susanne(dot)ebrecht(at)credativ(dot)de>
Subject: Re: [HACKERS] 8.2 features?
Date: 2006-07-28 20:42:17
Message-ID: 44CA76A9.8070101@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers pgsql-patches

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>
>>Are you going to apply this? Seems it is ready.
>
> I thought Joe was off in a corner doing a whole new version.
> (I'm willing to help if he needs help...)
>

Yeah, I was going to post the latest tonight.

I'm afraid though that after 2 or so days heading down the last path you
suggested (namely making a new jointree leaf node) I was having trouble,
and at the same time came to the conclusion that adding a new RTE was
alot cleaner and made more sense to me. So I'm hoping you won't want to
send me back to the drawing board again. I believe I have cleaned up the
things you objected to:

1. Now I'm not doing both alternative -- the targetlists are only
attached to the RTE from the point of parse analysis onward.
2. I've eliminated the tuplestore in favor of runtime evaluation
of the targetlists which are in an array (allowing forward or
backward scanning -- although I haven't tested the latter yet).

I've also solved the INSERT related issues that I had earlier:

1. Fixed the rules regression test -- now all regression tests pass
2. Fixed evaluation of DEFAULT values
3. Improved memory consumption and speed some more -- basically
we are approximately equal to mysql as long as we don't swap,
and we consume about twice the RAM as mysql instead of several
times as much. I have more analysis of memory use I'd also like
to share later.
4. I think the INSERT part of this is ready to go basically, but
I need a bit more time to test corner cases.

I've made some progress on "SELECT ... FROM (VALUES ...) AS ..."

1. No more shift/reduce issues
2. The ValuesScan work and memory improvements mentioned above
applies here too.
3. This part still needs the most work though.

I'll post a patch in a few hours -- there is some debug code in there
currently that I should clean up before I send it to the list.

BTW, I'm reserving Saturday, Sunday, and Monday (taking Monday off from
my day job) to work on outstanding issues. I can continue to work
through the end of next Friday, 4 August. After that I'm heading to
Germany on a business trip and my "spare" time will evaporate for a few
weeks.

Joe

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Joe Conway 2006-07-29 06:50:05 Re: [HACKERS] 8.2 features?
Previous Message Bruce Momjian 2006-07-28 19:54:50 Re: [HACKERS] 8.2 features?

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-07-28 20:46:33 Re: lastval exposes information that currval does not
Previous Message Phil Frost 2006-07-28 20:42:11 Re: lastval exposes information that currval does not

Browse pgsql-patches by date

  From Date Subject
Next Message Marko Kreen 2006-07-28 21:13:52 Re: [HACKERS] [PATCH] Provide 8-byte transaction IDs to user level
Previous Message Tom Lane 2006-07-28 20:08:24 Re: [HACKERS] pg_regress breaks on msys