Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

2014-08-02 Thread Peter Geoghegan
Consider the "cities" table I've played around with throughout the development of this patch: postgres=# select tablename, attname, n_distinct, correlation from pg_stats where attname in ('country', 'province', 'city'); tablename | attname | n_distinct | correlation ---+--+--

Re: [HACKERS] Proposed changing the definition of decade for date_trunc and extract

2014-08-02 Thread Mike Swanson
On Fri, 2014-08-01 at 22:28 -0700, Mike Swanson wrote: > I'd also argue that the current function basing the logic from > definition #2 has limited use even when you want to use it for such. > If you want to generate text for '(decades)s' you'd have to do: > SELECT extract('year' from date_trunc(

Re: [HACKERS] a fast bloat measurement tool (was Re: Measuring relation free space)

2014-08-02 Thread Amit Kapila
On Thu, Apr 3, 2014 at 3:11 AM, Abhijit Menon-Sen wrote: > > This is a follow-up to the thread at > http://www.postgresql.org/message-id/4eb5fa1b.1090...@2ndquadrant.com > > A quick summary: that thread proposed adding a relation_free_space() > function to the pageinspect extension. > Various rev

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

2014-08-02 Thread Peter Geoghegan
On Sat, Aug 2, 2014 at 2:45 AM, Peter Geoghegan wrote: > I'll post something over the weekend. Attached is a cumulative pair of patches generated using git-format-patch. I refer anyone who wants to know how the two parts fit together to the commit messages of each patch. In passing, I have added

[HACKERS] 9.5: Better memory accounting, towards memory-bounded HashAgg

2014-08-02 Thread Jeff Davis
Attached is a patch that explicitly tracks allocated memory (the blocks, not the chunks) for each memory context, as well as its children. This is a prerequisite for memory-bounded HashAgg, which I intend to submit for the next CF. Hashjoin tracks the tuple sizes that it adds to the hash table, wh

[HACKERS] Looked at TODO:Considering improving performance of computing CHAR() value lengths

2014-08-02 Thread John Cochran
Greetings, I took at look at the TODO list and got interested in the possible optimization of the bcTruelen() function. Read the archived messages about that subject and decided to see what could be done. I tested the performance of 5 different versions of bcTruelen(). 1. The code as it exists in

Re: [HACKERS] Fixed redundant i18n strings in json

2014-08-02 Thread Daniele Varrazzo
I'd definitely replace /arg/argument/. Furthermore I'd avoid the form "argument 1: something is wrong": the string is likely to end up in sentences with other colons so I'd rather use "something is wrong at argument 1". Is the patch attached better? Cheers, -- Daniele On Thu, Jul 31, 2014 at 1:

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

2014-08-02 Thread Peter Geoghegan
On Sat, Aug 2, 2014 at 1:15 AM, Heikki Linnakangas wrote: > Great, I'll wait for the patch. I'll post something over the weekend. > Do you mean: > > a) you don't understand what the patch should look like? or > b) you don't understand why it's been requested? > > If a), I admit I don't remember

Re: [HACKERS] B-Tree support function number 3 (strxfrm() optimization)

2014-08-02 Thread Heikki Linnakangas
On 08/02/2014 08:16 AM, Peter Geoghegan wrote: On Fri, Aug 1, 2014 at 8:57 PM, Noah Misch wrote: Robert, Heikki and maybe Alvaro requested and/or explained this split back in April. The fact that the would-be first patch was discussed and rejected in the past does not counter that request. (I