[HACKERS] Re: proposal: ignore null fields in not relation type composite type based constructors

2014-09-08 6:27 GMT+02:00 Stephen Frost : > * Pavel Stehule (pavel.steh...@gmail.com) wrote: > > ignore_nulls in array_to_json_pretty probably is not necessary. On second > > hand, the cost is zero, and we can have it for API consistency. > > I'm willing to be persuaded either way on this, really.

Re: [HACKERS] gist vacuum gist access

On 09/07/2014 05:11 PM, Костя Кузнецов wrote: hello. i recode vacuum for gist index. all tests is ok. also i test vacuum on table size 2 million rows. all is ok. on my machine old vaccum work about 9 second. this version work about 6-7 sec . review please. If I'm reading this correctly, the pat

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

I wrote: > I gave it a spin and could not find any undesirable behaviour, and the > output of EXPLAIN ANALYZE looks like I'd expect. > > I noticed that you use the list length of fdw_private to check if > the UPDATE or DELETE is pushed down to the remote server or not. > > While this works fine,

Re: [HACKERS] gist vacuum gist access

On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas wrote: > On 09/07/2014 05:11 PM, Костя Кузнецов wrote: > >> hello. >> i recode vacuum for gist index. >> all tests is ok. >> also i test vacuum on table size 2 million rows. all is ok. >> on my machine old vaccum work about 9 second. this versio

Re: [HACKERS] gist vacuum gist access

On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov wrote: > On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas < > hlinnakan...@vmware.com> wrote: > >> On 09/07/2014 05:11 PM, Костя Кузнецов wrote: >> >>> hello. >>> i recode vacuum for gist index. >>> all tests is ok. >>> also i test vacuum on

Re: [HACKERS] gist vacuum gist access

On 09/08/2014 11:08 AM, Alexander Korotkov wrote: On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas wrote: On 09/07/2014 05:11 PM, Костя Кузнецов wrote: hello. i recode vacuum for gist index. all tests is ok. also i test vacuum on table size 2 million rows. all is ok. on my machine old va

Re: [HACKERS] gist vacuum gist access

On 09/08/2014 11:19 AM, Alexander Korotkov wrote: On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov wrote: On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: In the b-tree code, we solved that problem back in 2006, so it can be done but requires a bit mor

Re: [HACKERS] add modulo (%) operator to pgbench

Hi, Here is the review result. #1. Patch compatibility Little bit hunk, but it can patch to latest master. #2. Functionality No problem. #3. Documentation I think modulo operator explanation should put at last at the doc line. Because the others are more frequently used. #4. Algorithm You prop

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

(2014/09/08 16:18), Albe Laurenz wrote: I wrote: I gave it a spin and could not find any undesirable behaviour, and the output of EXPLAIN ANALYZE looks like I'd expect. Thank you for the review! I noticed that you use the list length of fdw_private to check if the UPDATE or DELETE is pushed

Re: [HACKERS] pg_receivexlog and replication slots

On Wed, Sep 3, 2014 at 11:40 PM, Robert Haas wrote: > On Sun, Aug 31, 2014 at 9:45 AM, Magnus Hagander wrote: >> Do we really want those Asserts? There is not a single Assert in >> bin/pg_basebackup today - as is the case for most things in bin/. We >> typically use regular if statements for thin

Re: [HACKERS] Spinlocks and compiler/memory barriers

On 2014-09-04 14:19:47 +0200, Andres Freund wrote: > Yes. I plan to push the patch this weekend. Sorry for the delay. I'm about to push this. Is it ok to first push it to master and only backpatch once a couple buildfarm cycles haven't complained? Greetings, Andres Freund -- Andres Freund

Re: [HACKERS] gist vacuum gist access

On Mon, Sep 8, 2014 at 12:51 PM, Heikki Linnakangas wrote: > On 09/08/2014 11:19 AM, Alexander Korotkov wrote: > >> On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov > > >> wrote: >> >> On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas < >>> hlinnakan...@vmware.com> wrote: >>> >>> In the b-

Re: [HACKERS] postgres_fdw behaves oddly

(2014/09/02 18:55), Etsuro Fujita wrote: > (2014/09/01 20:15), Etsuro Fujita wrote: >> While working on [1], I've found that postgres_fdw behaves oddly: I've revised the patch a bit further. Please find attached a patch. Thanks, Best regards, Etsuro Fujita *** a/contrib/postgres_fdw/deparse.c -

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund wrote: > On 2014-09-04 14:19:47 +0200, Andres Freund wrote: >> Yes. I plan to push the patch this weekend. Sorry for the delay. > > I'm about to push this. Is it ok to first push it to master and only > backpatch once a couple buildfarm cycles haven't

Re: [HACKERS] add modulo (%) operator to pgbench

Hello Mutsumara-san, #3. Documentation I think modulo operator explanation should put at last at the doc line. Because the others are more frequently used. So I like patch3 which is simple and practical. Ok. If you agree or reply my comment, I will mark ready for commiter. Please find

Re: [HACKERS] Spinlocks and compiler/memory barriers

Andres Freund writes: > On 2014-09-04 14:19:47 +0200, Andres Freund wrote: >> Yes. I plan to push the patch this weekend. Sorry for the delay. > I'm about to push this. Is it ok to first push it to master and only > backpatch once a couple buildfarm cycles haven't complained? It makes for a clea

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Mon, Sep 8, 2014 at 10:07 AM, Tom Lane wrote: > It makes for a cleaner commit history if you push concurrently into > all the branches you intend to patch. That also gives more buildfarm > runs, which seems like a good thing for this sort of patch. > > That is, assuming that we ought to backpa

Re: [HACKERS] PL/pgSQL 2

On Fri, Sep 5, 2014 at 6:18 PM, Andrew Dunstan wrote: > > On 09/05/2014 12:37 PM, Merlin Moncure wrote: >> >> On Thu, Sep 4, 2014 at 6:40 PM, Florian Pflug wrote: Cost of hidden IO cast is negative too. If we can change it, then we can increase a sped. >>> >>> But the whole power o

Re: [HACKERS] Spinlocks and compiler/memory barriers

On Mon, Sep 8, 2014 at 10:08:04AM -0400, Robert Haas wrote: > On Mon, Sep 8, 2014 at 8:07 AM, Andres Freund wrote: > > On 2014-09-04 14:19:47 +0200, Andres Freund wrote: > >> Yes. I plan to push the patch this weekend. Sorry for the delay. > > > > I'm about to push this. Is it ok to first push it

Re: [HACKERS] add modulo (%) operator to pgbench

Hi Fabien-san, Thank you for your fast work! 2014-09-08 23:08 GMT+09:00 Fabien COELHO : > > Hello Mutsumara-san, > > #3. Documentation >> I think modulo operator explanation should put at last at the doc line. >> Because the others are more frequently used. >> > > So I like patch3 which is sim

Re: [HACKERS] Spinlocks and compiler/memory barriers

Robert Haas writes: > But what we're talking about here is a bug fix for Sparc. And surely > we ought to back-patch that. Ah. OK, no objection. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

Re: [HACKERS] add modulo (%) operator to pgbench

The attached is seemed no problem. But I'd like to say about order of explanation in five formulas. Fix version is here. Please confirm, and I mark it for ready for commiter. I'm ok with this version. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] 9.5: Memory-bounded HashAgg

On Wed, Sep 3, 2014 at 7:34 PM, Tomas Vondra wrote: >> Well, I think you're certainly right that a hash table lookup is more >> expensive than modulo on a 32-bit integer; so much is obvious. But if >> join can increase the number of batches on the fly, but only by >> doubling it, so you might go

Re: [HACKERS] proposal (9.5) : psql unicode border line styles

Hi I removed dynamic allocation and reduced patch size. What I tested a old unicode style is same as new unicode style. There nothing was changed .. some fields are specified in refresh_utf8format function Regards Pavel 2014-09-08 4:44 GMT+02:00 Stephen Frost : > Pavel, > > * Pavel Stehul

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Thu, Sep 4, 2014 at 6:38 PM, David Johnston wrote: > The implied suggestion is that if I do find any other areas that look like > they need fixing - even in the same file - I should separate them out into a > separate patch. Yes. > Though I have seen various "while I was in there I also > fix

Re: [HACKERS] gist vacuum gist access

On 09/08/2014 03:26 PM, Alexander Korotkov wrote: On Mon, Sep 8, 2014 at 12:51 PM, Heikki Linnakangas wrote: On 09/08/2014 11:19 AM, Alexander Korotkov wrote: On Mon, Sep 8, 2014 at 12:08 PM, Alexander Korotkov wrote: On Mon, Sep 8, 2014 at 11:13 AM, Heikki Linnakangas < hlinnakan...

Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: [HACKERS] HEAD seems to generate larger WAL regarding GIN index

On Sun, Aug 17, 2014 at 7:46 PM, Fujii Masao wrote: > > Thanks for reviewing the patch! ISTM that I failed to make the patch from > my git repository... Attached is the rebased version. > I get some compiler warnings on v2 of this patch: reloptions.c:219: warning: excess elements in struct ini

Re: [HACKERS] [v9.5] Custom Plan API

On Thu, Sep 4, 2014 at 7:57 PM, Kouhei Kaigai wrote: > Regarding to the attached three patches: > [1] custom-path and hook > It adds register_custom_path_provider() interface for registration of > custom-path entrypoint. Callbacks are invoked on set_plain_rel_pathlist > to offer alternative scan p

Re: [HACKERS] Scaling shared buffer eviction

On Fri, Sep 5, 2014 at 6:47 AM, Amit Kapila wrote: > Client Count/Patch_Ver (tps) 8 16 32 64 128 > HEAD 58614 107370 140717 104357 65010 > Patch 60092 113564 165014 213848 216065 > > This data is median of 3 runs, detailed report is attached with mail. > I have not repeated the test for all config

Re: [HACKERS] pgcrypto: PGP signatures

On Fri, Sep 5, 2014 at 4:38 AM, Marko Tiikkaja wrote: > Hi all, > > I've updated the patch with a number of changes: > 1) I've documented the current limitations of signatures > 2) I've expanded section F.25.3 to add information about signatures > (though I'm not sure why this part is in the

Re: [HACKERS] implement subject alternative names support for SSL connections

On 09/05/2014 07:30 PM, Alexey Klyukin wrote: On Thu, Sep 4, 2014 at 10:23 AM, Heikki Linnakangas wrote: Hmm. Perhaps we should use X509_NAME_get_index_by_NID + X509_NAME_get_entry instead of X509_NAME_get_text_by_NID. You could then pass the ASN1_STRING object to the certificate_name_entry_va

Re: [HACKERS] BRIN indexes - TRAP: BadArgument

/data1/pg_stuff/pg_installations/pgsql.minmax/lib' '--enable-depend' '--enable-cassert' '--enable-debug' '--with-perl' '--with-openssl' '--with-libxml' '--with-extra-version=_minmax_20140908_1809_0640c1bfc091' pgpatche

Re: [HACKERS] pgcrypto: PGP signatures

On 2014-09-08 7:30 PM, Jeff Janes wrote: On Fri, Sep 5, 2014 at 4:38 AM, Marko Tiikkaja wrote: I've also changed the behaviour when passing a message with a signature to the decrypt functions which don't verify signatures. They now report "ERROR: Wrong key or corrupt data" instead of decrypti

Re: [HACKERS] BRIN indexes - TRAP: BadArgument

Erik Rijkers wrote: > Log file says: > > TRAP: BadArgument("!(((context) != ((void *)0) && (const > Node*)((context)))->type) == T_AllocSetContext", File: > "mcxt.c", Line: 752) > 2014-09-08 19:54:46.071 CEST 30151 LOG: server process (PID 30336) was > terminated by signal 6: Aborted >

Re: [HACKERS] Scaling shared buffer eviction

On Fri, Sep 5, 2014 at 9:19 AM, Amit Kapila wrote: > On Fri, Sep 5, 2014 at 5:17 PM, Amit Kapila wrote: >> Apart from above, I think for this patch, cat version bump is required >> as I have modified system catalog. However I have not done the >> same in patch as otherwise it will be bit difficu

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

On Fri, Sep 5, 2014 at 3:23 PM, Tomas Vondra wrote: > as Heikki mentioned in his "commitfest status" message, this patch still > has no reviewers :-( Is there anyone willing to pick up that, together > with the 'dense allocation' patch (as those two are closely related)? > > I'm looking in Robert'

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

On Mon, Sep 8, 2014 at 1:09 AM, Amit Kapila wrote: >> > Don't you need a PG_TRY block here to reset pq_mq_busy? >> >> No. If shm_mq_sendv is interrupted, we can't use the shm_mq any more. >> But since that should only happen if an interrupt arrives while the >> queue is full, I think that's OK. >

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

On Mon, Sep 8, 2014 at 2:05 AM, Amit Kapila wrote: >> Another point about error handling is that to execute the sql in >> function pg_background_worker_main(), it starts the transaction >> which I think doesn't get aborted if error occurs > > For this I was just referring error handling code of >

Re: [HACKERS] ALTER TABLESPACE MOVE command tag tweak

Stephen Frost wrote: > Alvaro, > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > ALTER TABLE ALL IN TABLESPACE xyz > > which AFAICS should work since ALL is already a reserved keyword. > > Pushed to master and REL9_4_STABLE. Thanks. One more tweak --- the whole reason for fiddling with

Re: [HACKERS] proposal: plpgsql - Assert statement

On Fri, Sep 5, 2014 at 2:16 AM, Pavel Stehule wrote: > Assert is usually implemented as custom functions and used via PERFORM > statement now > > -- usual current solution > PERFORM Assert(some expression) > > I would to implement Assert as plpgsql internal statement due bigger > possibilities to

Re: [HACKERS] ALTER TABLESPACE MOVE command tag tweak

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > > ALTER TABLE ALL IN TABLESPACE xyz > > > which AFAICS should work since ALL is already a reserved keyword. > > > > Pushed to master and REL9_4_STABLE. > >

Re: [HACKERS] Scaling shared buffer eviction

On 5 September 2014 14:19, Amit Kapila wrote: > On Fri, Sep 5, 2014 at 5:17 PM, Amit Kapila > wrote: > > > > Apart from above, I think for this patch, cat version bump is required > > as I have modified system catalog. However I have not done the > > same in patch as otherwise it will be bit di

Re: [HACKERS] bad estimation together with large work_mem generates terrible slow hash joins

On 8.9.2014 22:44, Robert Haas wrote: > On Fri, Sep 5, 2014 at 3:23 PM, Tomas Vondra wrote: >> as Heikki mentioned in his "commitfest status" message, this patch >> still has no reviewers :-( Is there anyone willing to pick up that, >> together with the 'dense allocation' patch (as those two are >

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL] < ml-node+s1045698n5818200...@n5.nabble.com> wrote: > On Thu, Sep 4, 2014 at 6:38 PM, David Johnston > <[hidden email] > > wrote: > > > One of the trade-offs I mentioned...its more s

Re: [HACKERS] PQputCopyEnd doesn't adhere to its API contract

On Mon, Sep 8, 2014 at 6:19 PM, David Johnston wrote: > On Mon, Sep 8, 2014 at 11:45 AM, Robert Haas [via PostgreSQL] < > ml-node+s1045698n5818200...@n5.nabble.com> wrote: > >> On Thu, Sep 4, 2014 at 6:38 PM, David Johnston >> <[hidden email]

Re: [HACKERS] Scaling shared buffer eviction

On Mon, Sep 8, 2014 at 10:12 PM, Merlin Moncure wrote: > > On Fri, Sep 5, 2014 at 6:47 AM, Amit Kapila wrote: > > Client Count/Patch_Ver (tps) 8 16 32 64 128 > > HEAD 58614 107370 140717 104357 65010 > > Patch 60092 113564 165014 213848 216065 > > > > This data is median of 3 runs, detailed repor

Re: [HACKERS] proposal: plpgsql - Assert statement

On 09/05/2014 05:21 PM, Pavel Stehule wrote: > > *shrug* Doing it in SQL would probably break more stuff. I'm trying to > contain the damage. And arguably, this is mostly only useful in PL/PgSQL. I've wanted assertions in SQL enough that I often write trivial wrappers around `raise` in PL/PgSQ

Re: [HACKERS] proposal: plpgsql - Assert statement

On 09/09/2014 05:20 AM, Robert Haas wrote: > > I previously proposed RAISE ASSERT ... WHERE, which seems like a nice > variant of what we've already got, but perhaps this whole discussion > merely illustrates that it's hard to get more than 1 vote for any > proposal in this area. Well, you have P