Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 2014-09-29 09:51:45 +0300, Heikki Linnakangas wrote: > That said, it would be handy if the syntax was closer to MERGE. Aside from > the concurrency issues, it does the same thing, right? So how about making > the syntax identical to MERGE, except for swapping the MERGE keyword with > e.g. UPSERT

Re: [HACKERS] Add generate_series(numeric, numeric)

Hi, Nice patch! And welcome here. On Mon, Sep 29, 2014 at 12:42 PM, Платон Малюгин wrote: > Could you help to find mistakes? > This implementation is rather broken, particularly when thinking that this code could be used with a negative step... I also see no point in saving explicitly the step

Re: [HACKERS] Collation-aware comparisons in GIN opclasses

On 09/15/2014 06:28 PM, Alexander Korotkov wrote: Hackers, some GIN opclasses uses collation-aware comparisons while they don't need to do especially collation-aware comparison. Examples are text[] and hstore opclasses. Hmm. It would be nice to use the index for inequality searches, at least

Re: [HACKERS] Collation-aware comparisons in GIN opclasses

On Mon, Sep 29, 2014 at 11:48 AM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: > On 09/15/2014 06:28 PM, Alexander Korotkov wrote: > >> Hackers, >> >> some GIN opclasses uses collation-aware comparisons while they don't need >> to do especially collation-aware comparison. Examples are text

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 28 September 2014 21:31, Peter Geoghegan wrote: > On Sun, Sep 28, 2014 at 1:17 PM, Simon Riggs wrote: >> MERGE INTO tab USING VALUES ('foo') >> WHEN NOT MATCHED THEN >> INSERT (colB) >> WHEN MATCHED THEN >> UPDATE SET colB = NEW.p1 >> >> and throwing "ERROR: full syntax for MERGE not impleme

Re: [HACKERS] Replication identifiers, take 3

On 2014-09-27 12:11:16 -0400, Steve Singer wrote: > On 09/26/2014 06:05 PM, Andres Freund wrote: > >On 2014-09-26 14:57:12 -0400, Robert Haas wrote: > >Sure, it'll possibly not be trivial to move them elsewhere. On the other > >hand, the padding bytes have been unused for 8+ years without somebody

[HACKERS] initdb -S and tablespaces

Hi. I just noticed that initdb -S ("Safely write all database files to disk and exit") does (only) the following in perform_fsync: pre_sync_fname(pdir, true); walkdir(pg_data, pre_sync_fname); fsync_fname(pdir, true); walkdir(pg_data, fsync_fname); walkdir() reads the directory

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

> On Wed, Sep 17, 2014 at 7:40 PM, Kouhei Kaigai wrote: > > At this moment, I revised the above portion of the patches. > > create_custom_plan() was modified to call "PlanCustomPath" callback > > next to the initialization of tlist and clauses. > > > > It's probably same as what you suggested. >

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 29 September 2014 02:20, Peter Geoghegan wrote: > On Sun, Sep 28, 2014 at 6:15 PM, Gavin Flower > wrote: >>> What I have a problem with is using the MERGE syntax to match people's >>> preexisting confused ideas about what MERGE does. If we do that, it'll >>> definitely bite us when we go to ma

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 2014-09-28 19:51:36 +0100, Simon Riggs wrote: > On 27 September 2014 09:29, Andres Freund wrote: > > On 2014-09-27 10:23:33 +0300, Heikki Linnakangas wrote: > >> This patch has gotten a fair amount of review, and has been rewritten once > >> during the commitfest. I think it's pretty close to b

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 29 September 2014 08:02, Andres Freund wrote: > On 2014-09-29 09:51:45 +0300, Heikki Linnakangas wrote: >> That said, it would be handy if the syntax was closer to MERGE. Aside from >> the concurrency issues, it does the same thing, right? So how about making >> the syntax identical to MERGE, e

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 09/29/2014 05:10 PM, Simon Riggs wrote: > > Please go to some trouble to tidy things up so we have clarity that > *we* can see and decide for ourselves whether or not you are correct. Are you suggesting a wiki page to document the issues, discussions around each issue, etc? A summary mail? Som

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 2014-09-29 11:13:43 +0200, Andres Freund wrote: > I doubt it'll be hard to construct a case where it'll show. My first try > of using a pgbench scale 100, -M prepared, -cj8 with a custom file with > 1 write and 5 read transaction yielded the following on my laptop: Hm. On second thought that te

Re: [HACKERS] Patch to support SEMI and ANTI join removal

On Mon, Sep 29, 2014 at 2:41 AM, Andres Freund wrote: > On 2014-09-28 17:32:21 +1300, David Rowley wrote: > > My understanding of foreign keys is that any pending foreign key triggers > > will be executed just before the query completes, so we should only ever > > encounter pending foreign key tr

Re: [HACKERS] Patch to support SEMI and ANTI join removal

On 2014-09-28 10:41:56 -0400, Tom Lane wrote: > David Rowley writes: > > Please correct anything that sounds wrong here, but my understanding is > > that we'll always plan a query right before we execute it, with the > > exception of PREPARE statements where PostgreSQL will cache the query plan >

Re: [HACKERS] initdb -S and tablespaces

On 2014-09-29 14:09:01 +0530, Abhijit Menon-Sen wrote: > Hi. > > I just noticed that initdb -S ("Safely write all database files to disk > and exit") does (only) the following in perform_fsync: > > pre_sync_fname(pdir, true); > walkdir(pg_data, pre_sync_fname); > > fsync_fname(pdir,

Re: [HACKERS] initdb -S and tablespaces

At 2014-09-29 11:54:10 +0200, and...@2ndquadrant.com wrote: > > Note that the perform_fsync() *was* ok for its original purpose in > initdb. At the end of initdb there's no relevant tablespaces. But if > used *after* pg_upgrade, that's not necessarily the case. Right. So, since I'm writing a func

Re: [HACKERS] pg_receivexlog --status-interval add fsync feedback

> On 09/05/2014 08:51 AM, furu...@pm.nttdata.co.jp wrote: > >>> Thanks for the review! > >>> > >>> I understand the attention message wasn't appropriate. > >>> > >>> To report the write location, even If you do not specify a > >>> replication > >> slot. > >>> So the fix only appended messages. > >>

Re: [HACKERS] Options OUTPUT_PLUGIN_* controlling format are confusing (Was: Misleading error message in logical decoding)

On 2014-09-23 12:40:25 +0900, Michael Paquier wrote: > On Tue, Sep 23, 2014 at 4:59 AM, Robert Haas wrote: > > On Thu, Sep 18, 2014 at 11:21 AM, Michael Paquier > > wrote: > >> On Thu, Sep 18, 2014 at 9:56 AM, Andres Freund > >> wrote: > >>> On 2014-09-18 09:50:38 -0500, Michael Paquier wrote:

Re: [HACKERS] initdb -S and tablespaces

On 2014-09-29 15:43:32 +0530, Abhijit Menon-Sen wrote: > At 2014-09-29 11:54:10 +0200, and...@2ndquadrant.com wrote: > > > > Note that the perform_fsync() *was* ok for its original purpose in > > initdb. At the end of initdb there's no relevant tablespaces. But if > > used *after* pg_upgrade, that'

Re: [HACKERS] initdb -S and tablespaces

At 2014-09-29 12:59:09 +0200, and...@2ndquadrant.com wrote: > > So I'm afraid at least in a first patch it'll need to be a bit of > duplication. Fixing initdb's code back to 9.3 and the backend all > the way back to 9.0. OK, thanks, I'll submit two separate patches then. -- Abhijit -- Sent via

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 2014-09-29 11:31:11 +0200, Andres Freund wrote: > On 2014-09-29 11:13:43 +0200, Andres Freund wrote: > > I doubt it'll be hard to construct a case where it'll show. My first try > > of using a pgbench scale 100, -M prepared, -cj8 with a custom file with > > 1 write and 5 read transaction yielded

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

On 29 September 2014 09:48, Kouhei Kaigai wrote: >> On Wed, Sep 17, 2014 at 7:40 PM, Kouhei Kaigai wrote: >> > At this moment, I revised the above portion of the patches. >> > create_custom_plan() was modified to call "PlanCustomPath" callback >> > next to the initialization of tlist and clauses.

Re: [HACKERS] Patch to support SEMI and ANTI join removal

On 2014-09-29 22:42:57 +1300, David Rowley wrote: > On Mon, Sep 29, 2014 at 2:41 AM, Andres Freund > wrote: > > > On 2014-09-28 17:32:21 +1300, David Rowley wrote: > > > My understanding of foreign keys is that any pending foreign key triggers > > > will be executed just before the query complete

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

Hi, On 2014-09-22 10:39:32 +, Syed, Rahila wrote: > >Please find attached the patch to compress FPW. I've given this a quick look and noticed some things: 1) I don't think it's a good idea to put the full page write compression into struct XLogRecord. 2) You've essentially removed a lot o

Re: [HACKERS] pg_receivexlog and replication slots

On 2014-09-22 15:40:41 +0900, Michael Paquier wrote: > Updated patches attached. These are patches about pg_dump. I don't think these were the ones you wanted to attach... :) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x

Re: [HACKERS] Options OUTPUT_PLUGIN_* controlling format are confusing (Was: Misleading error message in logical decoding)

On Mon, Sep 29, 2014 at 7:50 PM, Andres Freund wrote: > What about the attached patch then? > Thanks for this update. This looks good. Here are a couple of small comments: 1) This sentence is correct English, but I don't recall seeing in the docs such a formulation: +Can only be used on

Re: [HACKERS] pg_receivexlog and replication slots

On Mon, Sep 29, 2014 at 9:42 PM, Andres Freund wrote: > On 2014-09-22 15:40:41 +0900, Michael Paquier wrote: > > Updated patches attached. > > These are patches about pg_dump. I don't think these were the ones you > wanted to attach... :) > Wah, sorry (bakabakashii...). Here they are. -- Michael

Re: [HACKERS] Options OUTPUT_PLUGIN_* controlling format are confusing (Was: Misleading error message in logical decoding)

On 2014-09-29 21:48:08 +0900, Michael Paquier wrote: > On Mon, Sep 29, 2014 at 7:50 PM, Andres Freund > wrote: > > > What about the attached patch then? > > > > Thanks for this update. This looks good. Here are a couple of small > comments: > 1) This sentence is correct English, but I don't reca

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

2014-09-29 20:26 GMT+09:00 Thom Brown : > On 29 September 2014 09:48, Kouhei Kaigai wrote: >>> On Wed, Sep 17, 2014 at 7:40 PM, Kouhei Kaigai wrote: >>> > At this moment, I revised the above portion of the patches. >>> > create_custom_plan() was modified to call "PlanCustomPath" callback >>> > ne

Re: [HACKERS] pgcrypto: PGP armor headers

On 09/27/2014 11:50 PM, Marko Tiikkaja wrote: Hi, On 9/25/14, 3:56 PM, I wrote: On 9/25/14 3:50 PM, Heikki Linnakangas wrote: Are you planning to post the main patch rebased on top of this soon? As in the next day or two? Otherwise I'll mark this as "Returned with feedback" for this commitfest

Re: [HACKERS] Missing newlines in verbose logs of pg_dump, introduced by RLS patch

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Mon, Sep 29, 2014 at 10:07 AM, Fabrízio de Royes Mello < > fabriziome...@gmail.com> wrote: > > > The schema name is missing... attached patch add it. > > > Ah, right, thanks. It didn't occur to me immediately :) Your patch looks > good to m

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 29 September 2014 10:27, Craig Ringer wrote: > On 09/29/2014 05:10 PM, Simon Riggs wrote: >> >> Please go to some trouble to tidy things up so we have clarity that >> *we* can see and decide for ourselves whether or not you are correct. > > Are you suggesting a wiki page to document the issues,

Re: [HACKERS] Patch to support SEMI and ANTI join removal

Andres Freund writes: > On 2014-09-28 10:41:56 -0400, Tom Lane wrote: >> If this optimization only works in that scenario, it's dead in the water, >> because that assumption is unsupportable. The planner does not in general >> use the same query snapshot as the executor, so even in an immediate-

Re: [HACKERS] Last Commitfest patches waiting review

On 09/27/2014 05:12 PM, Tom Lane wrote: Heikki Linnakangas writes: [ unreviewed patches ] Grouping Sets There has been a lot of discussion, but no decisions. See http://www.postgresql.org/message-id/87vbodhtvb@news-spur.riddles.org.uk. Would a committer be interested to take respon

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On 28 September 2014 08:40, Peter Geoghegan wrote: > On Sat, Sep 27, 2014 at 11:21 PM, Simon Riggs wrote: >> My request was for the following... >> >> Agree command semantics by producing these things >> * Explanatory documentation (Ch6.4 Data Manipulation - Upsert) > > Do you really think I coul

Re: [HACKERS] WITH CHECK and Column-Level Privileges

On Sat, Sep 27, 2014 at 1:19 PM, Dean Rasheed wrote: >> Also attached is a patch for 9.4 which does the same, but also removes >> the row reporting (completely) from the WITH CHECK case. It could be >> argued that it would be helpful to have it there also, perhaps, but I'm >> not convinced at thi

Re: [HACKERS] WITH CHECK and Column-Level Privileges

* Robert Haas (robertmh...@gmail.com) wrote: > On Sat, Sep 27, 2014 at 1:19 PM, Dean Rasheed > wrote: > >> Also attached is a patch for 9.4 which does the same, but also removes > >> the row reporting (completely) from the WITH CHECK case. It could be > >> argued that it would be helpful to have

Re: [HACKERS] Patch to support SEMI and ANTI join removal

On 2014-09-29 10:12:25 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-09-28 10:41:56 -0400, Tom Lane wrote: > >> If this optimization only works in that scenario, it's dead in the water, > >> because that assumption is unsupportable. The planner does not in general > >> use the same q

Re: [HACKERS] WITH CHECK and Column-Level Privileges

On Mon, Sep 29, 2014 at 10:26 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Sat, Sep 27, 2014 at 1:19 PM, Dean Rasheed >> wrote: >> >> Also attached is a patch for 9.4 which does the same, but also removes >> >> the row reporting (completely) from the WITH CHECK c

Re: [HACKERS] json (b) and null fields

On Sat, Sep 27, 2014 at 11:00 PM, Andrew Dunstan wrote: > On 09/27/2014 10:52 PM, Tom Lane wrote: >> Andrew Dunstan writes: >>> On 09/27/2014 06:27 PM, Tom Lane wrote: So my vote is for a separate function and no optional arguments. >>> >>> You mean like row_to_json_no_nulls() and json_

Re: [HACKERS] Patch to support SEMI and ANTI join removal

Andres Freund writes: > On 2014-09-29 10:12:25 -0400, Tom Lane wrote: >> I see. So why aren't we simply ignoring deferrable FKs when making the >> optimization? That pushes it back from depending on execution-time state >> (unsafe) to depending on table DDL (safe). > IIRC there's some scenarios

Re: [HACKERS] pgcrypto: PGP armor headers

On 9/29/14 3:02 PM, Heikki Linnakangas wrote: Thanks! I found the pgp_extract_armor_headers()'s signature quite weird, so I simplified that by making it always return arrays of keys and values. The callers is now responsible for returning all the keys (pgp_armor_header_keys) or finding the single

Re: [HACKERS] json (b) and null fields

* Robert Haas (robertmh...@gmail.com) wrote: > +1. I am sort of surprised that anyone things this null-stripping > behavior is something that ought to be part of core PostgreSQL instead > of, I don't know, relegated to an extension somewhere far from the > bright center of the galaxy. I've never

Re: [HACKERS] Replication identifiers, take 3

On Sat, Sep 27, 2014 at 12:11 PM, Steve Singer wrote: > If we were now increasing the WAL record size anyway for some unrelated > reason, would we be willing to increase it by a further 2 bytes for the node > identifier? Obviously not. Otherwise Andres would be proposing to put an OID in there i

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Mon, Sep 29, 2014 at 8:36 AM, Andres Freund wrote: > 1) I don't think it's a good idea to put the full page write compression >into struct XLogRecord. Why not, and where should that be put? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- S

Re: [HACKERS] Options OUTPUT_PLUGIN_* controlling format are confusing (Was: Misleading error message in logical decoding)

On Mon, Sep 29, 2014 at 9:03 AM, Andres Freund wrote: >> -except that changes are returned as bytea. >> +except that changes are returned as bytea and that it >> can >> +be used on slots using output plugins that only support binary >> output. > > Imo that's pretty much imp

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

On Mon, Sep 29, 2014 at 9:04 AM, Kohei KaiGai wrote: > Do we need to match the prototype of wrapper function with callback? Yes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On 2014-09-29 11:02:49 -0400, Robert Haas wrote: > On Mon, Sep 29, 2014 at 8:36 AM, Andres Freund wrote: > > 1) I don't think it's a good idea to put the full page write compression > >into struct XLogRecord. > > Why not, and where should that be put? Hah. I knew that somebody would pick tha

Re: [HACKERS] json (b) and null fields

On 09/29/2014 10:38 AM, Robert Haas wrote: On Sat, Sep 27, 2014 at 11:00 PM, Andrew Dunstan wrote: On 09/27/2014 10:52 PM, Tom Lane wrote: Andrew Dunstan writes: On 09/27/2014 06:27 PM, Tom Lane wrote: So my vote is for a separate function and no optional arguments. You mean like row_to_j

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On 2014-09-29 18:27:01 +0300, Heikki Linnakangas wrote: > On 09/29/2014 06:02 PM, Robert Haas wrote: > >On Mon, Sep 29, 2014 at 8:36 AM, Andres Freund wrote: > >>1) I don't think it's a good idea to put the full page write compression > >>into struct XLogRecord. > > > >Why not, and where shoul

Re: [HACKERS] KNN-GiST with recheck

On Mon, Sep 29, 2014 at 6:16 AM, Bruce Momjian wrote: > On Fri, Sep 26, 2014 at 10:49:42AM +0400, Alexander Korotkov wrote: > > Does this also fix the identical PostGIS problem or is there > something > > PostGIS needs to do? > > > > > > This patch provides general infrastructure for rech

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Fri, Sep 26, 2014 at 5:40 PM, Peter Geoghegan wrote: > I will be frank. Everyone knows that the nbtree locking parts of this > are never going to be committed over your objections. It cannot > happen. And yet, I persist in proposing that we go that way. I may be > stubborn, but I am not so stub

Re: [HACKERS] json (b) and null fields

Merlin, * Merlin Moncure (mmonc...@gmail.com) wrote: > Are you defining 'core' as 'supported by the core project' (in which > case I agree) or 'not an extension' (in which case I disagree). Which means you're suggesting it as an extension which lives in contrib..? Otherwise, I'm not following.

Re: [HACKERS] WITH CHECK and Column-Level Privileges

* Robert Haas (robertmh...@gmail.com) wrote: > Well, I think that's an acceptable approach from the point of view of > fixing the security exposure, but it's far from ideal. Good error > messages are important for usability. I can live with this as a > short-term fix, but in the long run I strong

Re: [HACKERS] open items for 9.4

On Sun, Sep 28, 2014 at 11:36 PM, Tom Lane wrote: > Josh Berkus writes: >> So, can we get Beta3 out now? > > If nobody else steps up and says they want to do some performance > testing, I'll push the latest lengths+offsets patch tomorrow. > > Are any of the other open items listed at > https://wi

Re: [HACKERS] json (b) and null fields

* Andrew Dunstan (and...@dunslane.net) wrote: > That said, doing this as an extension is probably a good way to go, > as I suggested upthread, since we could then make it available for > 9.4, rather than making people wait until 9.5. Two points on this- having it in 9.5 doesn't preclude someone fr

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On 09/29/2014 06:02 PM, Robert Haas wrote: On Mon, Sep 29, 2014 at 8:36 AM, Andres Freund wrote: 1) I don't think it's a good idea to put the full page write compression into struct XLogRecord. Why not, and where should that be put? It should be a flag in BkpBlock. - Heikki -- Sent

Re: [HACKERS] json (b) and null fields

On Mon, Sep 29, 2014 at 9:45 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> +1. I am sort of surprised that anyone things this null-stripping >> behavior is something that ought to be part of core PostgreSQL instead >> of, I don't know, relegated to an extension somewh

Re: [HACKERS] open items for 9.4

On Mon, Sep 29, 2014 at 5:53 PM, Andres Freund wrote: > On 2014-09-29 11:50:19 -0400, Robert Haas wrote: >> The items I see are: >> >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! >> >> The text seems to indicate that there's some disagreement on this >> point. I don't have a strong

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

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > Attached is a contrib module that lets you launch arbitrary command in > a background worker, and supporting infrastructure patches for core. Very cool! Started looking into this while waiting on a few CLOBBER_CACHE_ALWAYS runs to finish (ug

Re: [HACKERS] open items for 9.4

On 2014-09-29 11:50:19 -0400, Robert Haas wrote: > The items I see are: > > - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > > The text seems to indicate that there's some disagreement on this > point. I don't have a strong opinion on whether or not to keep the > GUC, but if we're go

Re: [HACKERS] open items for 9.4

Andres Freund wrote: > On 2014-09-29 11:50:19 -0400, Robert Haas wrote: > > - pg_dump fails with --if-exists and blobs > > > > This looks like a 9.4 regression. > > Alvaro, IIRC you were looking at this one? I am. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Develop

Re: [HACKERS] json (b) and null fields

Stephen Frost writes: > * Andrew Dunstan (and...@dunslane.net) wrote: >> That said, doing this as an extension is probably a good way to go, >> as I suggested upthread, since we could then make it available for >> 9.4, rather than making people wait until 9.5. > Two points on this- having it in 9

Re: [HACKERS] open items for 9.4

Dne 29.9.2014 18:00 "Magnus Hagander" napsal(a): > > On Mon, Sep 29, 2014 at 5:53 PM, Andres Freund wrote: > > On 2014-09-29 11:50:19 -0400, Robert Haas wrote: > >> The items I see are: > >> > >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > >> > >> The text seems to indicate that

Re: [HACKERS] jsonb format is pessimal for toast compression

Bruce Momjian writes: > On Thu, Sep 25, 2014 at 02:39:37PM -0400, Tom Lane wrote: >> BTW, it seems like there is consensus that we ought to reorder the items >> in a jsonb object to have keys first and then values, independently of the >> other issues under discussion. This means we *will* be bre

Re: [HACKERS] json (b) and null fields

On Sep 29, 2014, at 9:09 AM, Tom Lane wrote: > I seem to recall that we've run into practical difficulties with moving > extensions into core. It might be OK for a functions-only extension > though. It does make upgrading difficult, though, as I’ve learned the hard way with when upgrading from

Re: [HACKERS] jsonb format is pessimal for toast compression

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Bruce Momjian writes: > > On Thu, Sep 25, 2014 at 02:39:37PM -0400, Tom Lane wrote: > >> BTW, it seems like there is consensus that we ought to reorder the items > >> in a jsonb object to have keys first and then values, independently of the > >> other issu

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 8:31 AM, Robert Haas wrote: > I'll be frank, too. Heikki doesn't need to persuade you to go his > way, because everyone other than yourself who has looked at this > problem has come up with a design that looks like his. Andres suggested something that is very roughly comp

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

On Mon, Sep 29, 2014 at 12:05 PM, Stephen Frost wrote: > Perhaps I'm just being a bit over the top, but all this per-character > work feels a bit ridiculous.. When we're using MAXIMUM_ALIGNOF, I > suppose it's not so bad, but is there no hope to increase that and make > this whole process more ef

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 10:37 AM, Peter Geoghegan wrote: > But more likely, somebody will >> go find some other bit space that can be used to do this. My concerns have nothing to do with the availability of bit space, obviously. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgs

[HACKERS] effective_io_concurrency documentation

The documentation of effective_io_concurrency says Asynchronous I/O depends on an effective posix_fadvise function, which some operating systems lack. If the function is not present then setting this parameter to anything but zero will result in an error. This is not correct, bec

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 7:21 AM, Simon Riggs wrote: > If you were an ORM developer reading the PostgreSQL Release Notes for > 9.5, which URL would you visit to see a complete description of the > new feature, including how it works concurrently, locking and other > aspects. How would you check whe

Re: [HACKERS] jsonb format is pessimal for toast compression

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Done --- 201409291 is the cutover point. > Just to clarify- the commit bumped the catversion to 201409292, so > version <= 201409291 has the old format while version > 201409291 has > the new format. There was no 201409291, so I s

Re: [HACKERS] jsonb format is pessimal for toast compression

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Done --- 201409291 is the cutover point. > > > Just to clarify- the commit bumped the catversion to 201409292, so > > version <= 201409291 has the old format while version > 201409291 ha

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 12:02 AM, Andres Freund wrote: > On 2014-09-29 09:51:45 +0300, Heikki Linnakangas wrote: >> That said, it would be handy if the syntax was closer to MERGE. Aside from >> the concurrency issues, it does the same thing, right? So how about making >> the syntax identical to ME

Re: [HACKERS] open items for 9.4

On 09/29/2014 08:53 AM, Andres Freund wrote: >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! >> > >> > The text seems to indicate that there's some disagreement on this >> > point. I don't have a strong opinion on whether or not to keep the >> > GUC, but if we're going to remove it

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 2:27 AM, Craig Ringer wrote: >> Please go to some trouble to tidy things up so we have clarity that >> *we* can see and decide for ourselves whether or not you are correct. > > Are you suggesting a wiki page to document the issues, discussions > around each issue, etc? A su

Re: [HACKERS] open items for 9.4

On 2014-09-29 11:28:07 -0700, Josh Berkus wrote: > On 09/29/2014 08:53 AM, Andres Freund wrote: > >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > >> > > >> > The text seems to indicate that there's some disagreement on this > >> > point. I don't have a strong opinion on whether or

Re: [HACKERS] open items for 9.4

Robert Haas writes: > The items I see are: > - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > The text seems to indicate that there's some disagreement on this > point. I don't have a strong opinion on whether or not to keep the > GUC, but if we're going to remove it it should proba

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On Fri, May 9, 2014 at 10:18 AM, Robert Haas wrote: > On Sat, May 3, 2014 at 4:31 AM, Dave Page wrote: >> Hamid@EDB; Can you please have someone configure anole to build git >> head as well as the other branches? Thanks. > > The test_shm_mq regression tests hung on this machine this morning. > Ha

Re: [HACKERS] open items for 9.4

On Mon, Sep 29, 2014 at 2:44 PM, Tom Lane wrote: > Robert Haas writes: >> The items I see are: > >> - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > >> The text seems to indicate that there's some disagreement on this >> point. I don't have a strong opinion on whether or not to keep

Re: [HACKERS] jsonb format is pessimal for toast compression

On Mon, Sep 29, 2014 at 12:19 AM, Josh Berkus wrote: > On 09/26/2014 06:20 PM, Josh Berkus wrote: > > Overall, I'm satisfied with the performance of the length-and-offset > > patch. > > Oh, also ... no bugs found. > > So, can we get Beta3 out now? > > -- > Josh Berkus > PostgreSQL Experts Inc. >

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On 2014-09-29 14:46:20 -0400, Robert Haas wrote: > On Fri, May 9, 2014 at 10:18 AM, Robert Haas wrote: > > On Sat, May 3, 2014 at 4:31 AM, Dave Page > > wrote: > >> Hamid@EDB; Can you please have someone configure anole to build git > >> head as well as the other branches? Thanks. > > > > The te

Re: [HACKERS] jsonb format is pessimal for toast compression

On 09/29/2014 11:49 AM, Arthur Silva wrote: > What's the call on the stride length? Are we going to keep it hardcoded? Please, yes. The complications caused by a variable stride length would be horrible. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers ma

Re: [HACKERS] jsonb format is pessimal for toast compression

Arthur Silva writes: > What's the call on the stride length? Are we going to keep it hardcoded? At the moment it's 32, but we could change it without forcing a new initdb. I ran a simple test that seemed to show 32 was a good choice, but if anyone else wants to try other cases, go for it.

Re: [HACKERS] trivial patch for dynahash logging

On Sat, Sep 27, 2014 at 3:09 PM, Tom Lane wrote: > Jeff Janes writes: > > under HASH_STATISTICS, the output reporting "this HTAB" upon destruction > is > > pretty useless. Which HTAB would this one be? It is not necessarily the > > most recently created one. > > > This makes it output the %p to

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Mon, Sep 29, 2014 at 2:14 AM, Simon Riggs wrote: > 1. SQL Standard MERGE (or a subset) > 2. MySQL Compatible syntax > 3. Something completely different > > If we go for (3), I would like to see a long and detailed explanation > of what is wrong with (1) and (2) before we do (3). That needs to b

Re: [HACKERS] effective_io_concurrency documentation

On Mon, Sep 29, 2014 at 10:41 AM, Peter Eisentraut wrote: > I think this is a mistake. For example, we allow setting ssl to false > even if SSL support is not compiled in. +1 -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your su

Re: [HACKERS] json (b) and null fields

2014-09-28 18:35 GMT+02:00 Andrew Dunstan : > > On 09/27/2014 11:58 PM, Stephen Frost wrote: > >> All, >> >> >> On Saturday, September 27, 2014, Andrew Dunstan > > wrote: >> >> >> On 09/27/2014 10:52 PM, Tom Lane wrote: >> >> Andrew Dunstan writes: >> >>

Re: [HACKERS] json (b) and null fields

2014-09-29 17:38 GMT+02:00 Stephen Frost : > * Andrew Dunstan (and...@dunslane.net) wrote: > > That said, doing this as an extension is probably a good way to go, > > as I suggested upthread, since we could then make it available for > > 9.4, rather than making people wait until 9.5. > > Two point

Re: [HACKERS] json (b) and null fields

2014-09-27 14:00 GMT+02:00 Stephen Frost : > Andrew, all, > > * Andrew Dunstan (and...@dunslane.net) wrote: > > I should have been paying a bit more attention to the recent work on > > adding an ignore_nulls option to row_to_json(). Here are some > > belated thought. I apologize to Pavel and Steph

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On Mon, Sep 29, 2014 at 2:52 PM, Andres Freund wrote: >> This happened again, and I investigated further. It looks like the >> postmaster knows full well that it's supposed to start more bgworkers: >> the ones that never get started are in the postmaster's >> BackgroundWorkerList, and StartWorker

Re: [HACKERS] json (b) and null fields

2014-09-29 21:23 GMT+02:00 Pavel Stehule : > > > 2014-09-27 14:00 GMT+02:00 Stephen Frost : > >> Andrew, all, >> >> * Andrew Dunstan (and...@dunslane.net) wrote: >> > I should have been paying a bit more attention to the recent work on >> > adding an ignore_nulls option to row_to_json(). Here are

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On 2014-09-29 15:24:55 -0400, Robert Haas wrote: > On Mon, Sep 29, 2014 at 2:52 PM, Andres Freund wrote: > > If that theory is true, wouldn't things get unstuck everytime a new > > connection comes in? Or 60 seconds have passed? That's not to say this > > isn't wrong, but still? > > There aren't

Re: [HACKERS] test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?)

On 2014-09-29 14:46:20 -0400, Robert Haas wrote: > On Fri, May 9, 2014 at 10:18 AM, Robert Haas wrote: > > On Sat, May 3, 2014 at 4:31 AM, Dave Page > > wrote: > >> Hamid@EDB; Can you please have someone configure anole to build git > >> head as well as the other branches? Thanks. > > > > The te

Re: [HACKERS] json (b) and null fields

On 09/29/2014 03:23 PM, Pavel Stehule wrote: 2014-09-27 14:00 GMT+02:00 Stephen Frost >: Andrew, all, * Andrew Dunstan (and...@dunslane.net ) wrote: > I should have been paying a bit more attention to the recent work on

Re: [HACKERS] open items for 9.4

On 2014-09-29 14:44:42 -0400, Tom Lane wrote: > Robert Haas writes: > > The items I see are: > > > - Remove xloginsert_slots/xloginsert_locks GUC - Not yet!! > > > The text seems to indicate that there's some disagreement on this > > point. I don't have a strong opinion on whether or not to kee

Re: [HACKERS] json (b) and null fields

2014-09-29 22:03 GMT+02:00 Andrew Dunstan : > > On 09/29/2014 03:23 PM, Pavel Stehule wrote: > >> >> >> 2014-09-27 14:00 GMT+02:00 Stephen Frost > sfr...@snowman.net>>: >> >> Andrew, all, >> >> * Andrew Dunstan (and...@dunslane.net >> ) wrote: >> > I sho

Re: [HACKERS] json (b) and null fields

Andrew Dunstan writes: > On 09/29/2014 03:23 PM, Pavel Stehule wrote: >> It is better than nothing, but it is not nice for JSON due 2x parsing. > JSON parsing is actually pretty darn fast. Every json (as opposed to > jsonb) function reparses the json. It's true that this is not nearly as > fas

  1   2   >