Re: [HACKERS] memory-related bugs

2011-03-13 Thread Noah Misch
On Sat, Mar 12, 2011 at 04:08:23PM +, Greg Stark wrote: On Sat, Mar 12, 2011 at 1:32 PM, Noah Misch n...@leadboat.com wrote: A suitably-instrumented run of make installcheck-world under valgrind turned up a handful of memory-related bugs: Nice work. How did you instrument things

Re: [HACKERS] memory-related bugs

2011-03-13 Thread Noah Misch
On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote: Noah Misch n...@leadboat.com writes: A suitably-instrumented run of make installcheck-world under valgrind turned up a handful of memory-related bugs: Hmm, interesting work, but I don't think I believe in the necessity for this

Re: [HACKERS] Collations versus user-defined functions

2011-03-13 Thread Martijn van Oosterhout
On Sat, Mar 12, 2011 at 06:06:33PM -0500, Tom Lane wrote: I remain unconvinced, because there are too many corner cases. Should collation propagate up out of a subselect? How about a CTE? You're starting to get into some pretty weird action-at-a-distance situations if so, analogous to the

Re: [HACKERS] Collations versus user-defined functions

2011-03-13 Thread Tom Lane
Martijn van Oosterhout klep...@svana.org writes: On Sat, Mar 12, 2011 at 06:06:33PM -0500, Tom Lane wrote: I remain unconvinced, because there are too many corner cases. Should collation propagate up out of a subselect? How about a CTE? You're starting to get into some pretty weird

Re: [HACKERS] Collations versus user-defined functions

2011-03-13 Thread Robert Haas
On Mar 13, 2011, at 8:25 AM, Martijn van Oosterhout klep...@svana.org wrote: What you're suggesting is going to lead to situations where the user sets a non-default collation on every field in every table in the database and depending on the query they will sometimes get the default collation

Re: [HACKERS] Collations versus user-defined functions

2011-03-13 Thread Martijn van Oosterhout
On Sun, Mar 13, 2011 at 01:16:36PM -0400, Tom Lane wrote: I said don't propegate the collation *state*, the collation should be propegated. Well, it's exactly that distinction that's bugging me. It seems a bit arbitrary if collation propagates in certain cases where collation state

[HACKERS] Better estimates of index correlation

2011-03-13 Thread Tom Lane
Currently, we don't measure any statistics about the ordering correlation of multi-column indexes, which means that btcostestimate has to pick a number out of the air if there's more than one column. We've been around on that at least once already: it used to use first column's correlation divided

Re: [HACKERS] Better estimates of index correlation

2011-03-13 Thread Joshua D. Drake
On Sun, 2011-03-13 at 19:40 -0400, Tom Lane wrote: I'm not planning to do anything about this idea right now, since I'm still hip-deep in collations, but I thought I'd throw it out to get it on the record. Comments? One question: Where is the overhead increase? JD