Обсуждение: Not-so-open items
There are several entries on the 8.2 open-items list that I think can be
removed:
Fix backward array comparison - subset
Done (this was redundant with the containment-operator item)
Store only active XIDs in subtransaction cache
Per my note just now, this probably should wait for 8.3.
Double vacuum speed on tables with no indexes
I changed the locking thing I was worried about. Unless Greg wants to
do some real-world performance measurements to confirm or refute that
change, I think this can be closed.
Fix excessive page checking for new btree split code
Per my note yesterday, I can't reproduce the misbehavior I saw six weeks
ago, so I recommend we leave the code alone.
Suppress error on bind parameters of unknown types
I haven't heard one single person speak up to say "yeah, that's a good
idea", so I conclude it probably isn't. Recommend we not change it.
BTW, pushing out an 8.1.5 is probably a good idea, but what's it doing
in the 8.2 open-items list? Especially in the "documentation" section?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > I changed the locking thing I was worried about. Unless Greg wants to > do some real-world performance measurements to confirm or refute that > change, I think this can be closed. I could do some if you're curious but my feeling is that the conservative choice is the right choice here regardless of what those numbers would show. So yeah, it should be closed. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Tom Lane wrote: > There are several entries on the 8.2 open-items list that I think can be > removed: > > Fix backward array comparison - subset > > Done (this was redundant with the containment-operator item) OK, that wasn't clear to me. > Store only active XIDs in subtransaction cache > > Per my note just now, this probably should wait for 8.3. OK, added to TODO. > Double vacuum speed on tables with no indexes > > I changed the locking thing I was worried about. Unless Greg wants to > do some real-world performance measurements to confirm or refute that > change, I think this can be closed. OK, removed. > > Fix excessive page checking for new btree split code > > Per my note yesterday, I can't reproduce the misbehavior I saw six weeks > ago, so I recommend we leave the code alone. OK, removed. > Suppress error on bind parameters of unknown types > > I haven't heard one single person speak up to say "yeah, that's a good > idea", so I conclude it probably isn't. Recommend we not change it. OK, removed. > BTW, pushing out an 8.1.5 is probably a good idea, but what's it doing > in the 8.2 open-items list? Especially in the "documentation" section? It is something that has to happen before final release, but is not a _code_ item, so I threw it there. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>>> Store only active XIDs in subtransaction cache
>>
>> Per my note just now, this probably should wait for 8.3.
> OK, added to TODO.
Actually, I realized this morning that there isn't anything there that
the current code doesn't do already. A subxact will never be assigned
an XID in the first place unless it stores tuples into the database.
(This means the do-I-need-to-do-something tests in
RecordSubTransactionCommit and RecordSubTransactionAbort are pretty much
redundant...)
So you might as well drop it from TODO --- perhaps there are variant
ideas we could use, but I don't know what they are.
regards, tom lane
OK, removed. --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >>> Store only active XIDs in subtransaction cache > >> > >> Per my note just now, this probably should wait for 8.3. > > > OK, added to TODO. > > Actually, I realized this morning that there isn't anything there that > the current code doesn't do already. A subxact will never be assigned > an XID in the first place unless it stores tuples into the database. > (This means the do-I-need-to-do-something tests in > RecordSubTransactionCommit and RecordSubTransactionAbort are pretty much > redundant...) > > So you might as well drop it from TODO --- perhaps there are variant > ideas we could use, but I don't know what they are. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +