Re: Patch queue triage

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Bruce Momjian <bruce@momjian.us> writes:
>> FYI, Tom, Heikki, I need one of you to post the list of patches and
>> where we think we are on each one, even if the list is imperfect.
>
> This message is an attempt to sort out which patch queue entries have
> no hope of getting into 8.3 (and so we shouldn't spend more time on them
> right now), which ones can get in but are waiting on their authors for
> more work, and which ones are ready for immediate review.

Thanks for this. This is exactly what we've been missing recently I think.

> * [PATCHES] non-recursive WITH clause support 
>       /Gregory Stark/
>
> I think the consensus is that we should wait for a more complete WITH
> implementation to be submitted, since this one creates compatibility
> issues without any real return in the form of added functionality.

I submitted it because it filled in a missing ANSI feature but nobody's piped
up saying they missed that feature so, sure.

> * [PATCHES] Concurrent psql v4 [WIP]  /stark/
>
> This is waiting on the author to change the API per list discussions; we
> can't apply something that is about to have some commands removed ...

I did finish the api changes -- though I'm not too happy with the names. I was
expecting the list to play the name game so I just put in placeholder names
originally. I'm adding documentation and example regression tests now. 

Also I'm trying to fix the cursor-mode FETCH_COUNT support which it breaks.
I'm thinking of once the first batch of rows arrives just going into a
synchronous function to fetch the rest of the resultsets.

> * Re: [HACKERS] Modifying TOAST thresholds  /Tom Lane/
>
> At this point it seems nothing will be done about this issue for 8.3.

I'm not sure anyone has an idea how to test it. TPCC isn't really useful
because it has a fixed size (500 byte) string buffer. Perhaps if we modified
it to have a random string length uniformly distributed between 0-2k ? But
even then it never does any scans based on that buffer. But the problem with
going with something more natural is that it'll be harder to tell exactly what
it's testing.

> * [HACKERS] tsearch_core patch for inclusion 
>       /Teodor Sigaev/
>
> Have we resolved whether the API and the dump/restore strategy are
> acceptable?  The code needs review too, but not till we've settled
> on the basic question whether we like the feature set.

Personally I actually do like the idea of promoting tsearch to first-class
citizen by giving it keywords and a place in the grammar. I think it's a more
fully integrated interface than the function based one. The only reason I
might think otherwise was if it was just a crutch for missing features it had
exposed that would be better implemented more generically. But I don't think
that's the case.

> * Re: [PATCHES] [Fwd: Deferred Transactions, Transaction Guarantee
>       and COMMITwithout waiting]  /Simon Riggs/
>
> Simon is on the hook to submit an updated patch.  I hope this one
> makes it in, as it looks like a really nice performance improvement
> for those who can use it; but the original patch seems overcomplicated.

I know Simon's really busy. I might be able to help with it if he wants.

> * Re: [PATCHES] LIMIT/SORT optimization  /Gregory Stark/
> * [PATCHES] updated SORT/LIMIT patch  /Gregory Stark/
>
> I will look at this.  I recall being concerned about whether there
> wasn't a cleaner way to introduce the required inter-node communication.

The next big thing to keep in mind in this area is a unique sort which would
need to know if there's a Unique node above it with the same key. If the
resulting inter-node communication arrangement has your blessing and can
handle that as well then I'll probably do that for 8.4.

Incidentally I would prefer it if you want to make changes that you explain
the changes to me and let me make them. It gives me a better chance to
understand what the changes really are and the motivation than trying to read
a patch later and understand why you made the changes you did. I understand
sometimes it's easier to just write the code than to explain the idea to
someone else and then review the resulting code though and there's already
enough work your plate so if that's the case then so be it.


--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com