Re: [HACKERS] Use unique index for longer pathkeys.

On Tue, Jul 15, 2014 at 2:17 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > Hi, the attached is the revised version. Thanks Horiguchi-San for the updated patch. Today while looking into updated patch, I was wondering why can't we eliminate useless keys in query_pathkeys when

Re: [HACKERS] Proposal for updating src/timezone

Agreed. Right now, I'm seeing about updating zic.c to match the IANA code combined with the modifications that postgres did to it. So far, it doesn't look like many functional changes have been done, but due to the use of pgindent, there's a LOT of cosmetic changes that add one heck of a lot of noi

Re: [HACKERS] Proposal for updating src/timezone

Hi, On Sat, Jul 19, 2014 at 09:28:25AM -0400, John Cochran wrote: > Agreed. Right now, I'm seeing about updating zic.c to match the IANA code > combined with the modifications that postgres did to it. So far, it doesn't > look like many functional changes have been done, but due to the use of > pg

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On 14.7.2014 06:29, Stephen Frost wrote: > Tomas, > > * Tomas Vondra (t...@fuzzy.cz) wrote: >> On 6.7.2014 17:57, Stephen Frost wrote: >>> * Tomas Vondra (t...@fuzzy.cz) wrote: I can't find the thread / test cases in the archives. I've found this thread in hackers: http://www.p

Re: [HACKERS] tweaking NTUP_PER_BUCKET

Tomas Vondra writes: > I've reviewed the two test cases mentioned here, and sadly there's > nothing that can be 'fixed' by this patch. The problem here lies in the > planning stage, which decides to hash the large table - we can't fix > that in the executor. We've heard a couple reports before of

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On 13.7.2014 21:32, Tomas Vondra wrote: > The current patch only implemnents this for tuples in the main hash > table, not for skew buckets. I plan to do that, but it will require > separate chunks for each skew bucket (so we can remove it without > messing with all of them). The chunks for skew

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On 19.7.2014 20:24, Tom Lane wrote: > Tomas Vondra writes: >> I've reviewed the two test cases mentioned here, and sadly there's >> nothing that can be 'fixed' by this patch. The problem here lies in the >> planning stage, which decides to hash the large table - we can't fix >> that in the executo

Re: [HACKERS] Proposal for updating src/timezone

On Sat, Jul 19, 2014 at 11:58 AM, Michael Banck wrote: SNIP > > Maybe if you pgindent the IANA code as well, you can more easily diff > the actual changes between the two, did you try that? > > > Michael > Unfortunately, pgindent doesn't work well with the IANA code as evident by some previous ch

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On 19.7.2014 20:28, Tomas Vondra wrote: > On 19.7.2014 20:24, Tom Lane wrote: >> Tomas Vondra writes: >>> I've reviewed the two test cases mentioned here, and sadly there's >>> nothing that can be 'fixed' by this patch. The problem here lies in the >>> planning stage, which decides to hash the lar

Re: [HACKERS] tweaking NTUP_PER_BUCKET

On 19.7.2014 23:07, Tomas Vondra wrote: > On 19.7.2014 20:28, Tomas Vondra wrote: > For the first case, a WARNING at the end of estimate_hash_bucketsize > says this: > > WARNING: nbuckets=8388608.00 estfract=0.01 > WARNING: nbuckets=65536.00 estfract=0.000267 > > There are 4.3M rows in the

Re: [HACKERS] Proposal for updating src/timezone

On 20/07/14 06:30, John Cochran wrote: On Sat, Jul 19, 2014 at 11:58 AM, Michael Banck > wrote: SNIP Maybe if you pgindent the IANA code as well, you can more easily diff the actual changes between the two, did you try that? Michael Unfortunately, pgind

Re: [HACKERS] Making joins involving ctid work for the benefit of UPSERT

On Fri, Jul 18, 2014 at 11:23 AM, Andres Freund wrote: > Meh. A understandable syntax wouldn't require the pullups with a special > scan node and such. Well, in general ExecModifyTable()/ExecUpdate() trusts the tid passed to match the qual in the query. Unless you're willing to give up on the ide

[HACKERS] SQL MERGE is quite distinct from UPSERT

Someone asked me privately why we weren't immediately pursuing SQL MERGE, as opposed to yet another non-standard variant of UPSERT (UPSERT is loosely defined here as an insert-or-update DML command that goes to update based on would-be unique constraint violations, and does one or the other *atomic

Re: [HACKERS] [bug fix] pg_ctl always uses the same event source

On Fri, Jul 18, 2014 at 7:08 PM, MauMau wrote: > > From: "Magnus Hagander" > >> On Fri, Jul 18, 2014 at 5:33 AM, Amit Kapila wrote: >>> >>> On Thu, Jul 17, 2014 at 4:51 PM, Magnus Hagander >>> wrote: Did anyone actually test this patch? :) I admit I did not build it on