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
>
>
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
>> Live 522's (LSN: logid 29, recoff 0xd1fade3c) previous points to
>> the zeroed out 523 block. Note that this seems to be latest LSN in the
>> data file.
>>
>
> So do you have logs from the server when it was restarted? It should
> say how far it recovered before it started up
>
Unfortunate
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
On Mar 13, 2011, at 8:25 AM, Martijn van Oosterhout 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 anyway.
Not t
Martijn van Oosterhout 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 action-at-a-distanc
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 th
On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote:
> Noah Misch 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 kluge:
On Sat, Mar 12, 2011 at 04:08:23PM +, Greg Stark wrote:
> On Sat, Mar 12, 2011 at 1:32 PM, Noah Misch 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 so valg
