Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Hi, On 2017-03-30 16:43:41 +0530, Pavan Deolasee wrote: > Looks like OID conflict to me.. Please try rebased set. Pavan, Alvaro, everyone: I know you guys are working very hard on this, but I think at this point it's too late to commit this for v10. This is patch that's affecting the on-disk

Re: [HACKERS] Logical decoding on standby

On 2017-03-30 15:26:02 +0100, Simon Riggs wrote: > On 30 March 2017 at 09:07, Craig Ringer wrote: > > > Attached. > > * Cleaned up in 3 places > * Added code for faked up RunningTransactions in xlog.c > * Ensure catalog_xmin doesn't go backwards > > All else looks good.

[HACKERS] PG_GETARG_GISTENTRY?

Hi, we have a good number of '(GISTENTRY *) PG_GETARG_POINTER(n)' in our code - looks a bit better & shorter to have PG_GETARG_GISTENTRY(n). Arugments against? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscrip

Re: [HACKERS] Schedule and Release Management Team for PG10

On 2017-03-29 16:04:50 -0300, Alvaro Herrera wrote: > Tom Lane wrote: > > > My own thought is that there's room for at least a few days' slop in > > the end date of the final commitfest, depending on what patches remain > > open and what the prospects are for getting them done. (In the past > >

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi, On 2017-03-27 22:33:03 -0700, Andres Freund wrote: > On 2017-03-23 20:35:09 +1300, Thomas Munro wrote: > > Here is a new patch series responding to feedback from Peter and Andres: > > Here's a review of 0007 & 0010 together - they're going to have to be > a

Re: [HACKERS] Protection lost in expression eval changeover

On 2017-03-28 15:24:28 -0400, Tom Lane wrote: > I wrote: > > Andres Freund <and...@anarazel.de> writes: > >> On 2017-03-28 14:43:38 -0400, Tom Lane wrote: > >>> I don't see a strong reason why we need to allow a dropped column to go > >>> to nul

Re: [HACKERS] Protection lost in expression eval changeover

On 2017-03-28 14:43:38 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-28 13:52:50 -0400, Tom Lane wrote: > >> So it seems like we are missing some needed protection. I'm inclined > >> to think that it'd be all right t

Re: [HACKERS] Protection lost in expression eval changeover

ed directly via tts_values/isnull. */ if (unlikely(thisatt->attisdropped)) { values[attnum] = (Datum) 0; isnull[attnum] = true; } It's annoying to add a branch there, it's a pretty hot function, but it seems like quite a worthwhile safety measure. Greetings, Andres Freund --

Re: [HACKERS] Today's failures on buildfarm member longfin

just use memcpy instead of direct assignment, but that seems too complicated. I'd personally just go with Aleksander's casts. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical decoding on standby

Hi, On 2017-03-27 16:03:48 +0800, Craig Ringer wrote: > On 27 March 2017 at 14:08, Craig Ringer wrote: > > > So this patch makes ReplicationSlotAcquire check that the slot > > database matches the current database and refuse to acquire the slot > > if it does not. > >

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-03-28 15:55:15 +0100, Simon Riggs wrote: > On 28 March 2017 at 15:38, Andres Freund <and...@anarazel.de> wrote: > > On 2017-03-28 15:32:49 +0100, Simon Riggs wrote: > >> On 28 March 2017 at 03:53, Craig Ringer <cr...@2ndquadrant.com> wrote: > >> >

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-03-28 15:32:49 +0100, Simon Riggs wrote: > On 28 March 2017 at 03:53, Craig Ringer <cr...@2ndquadrant.com> wrote: > > On 28 March 2017 at 09:25, Andres Freund <and...@anarazel.de> wrote: > > > >> If you actually need separate decoding of 2PC, then y

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On 2017-03-23 20:35:09 +1300, Thomas Munro wrote: > Here is a new patch series responding to feedback from Peter and Andres: Here's a review of 0007 & 0010 together - they're going to have to be applied together anyway... diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-03-28 03:30:28 +0100, Simon Riggs wrote: > On 28 March 2017 at 02:25, Andres Freund <and...@anarazel.de> wrote: > > On 2017-03-28 04:12:41 +0300, Stas Kelvich wrote: > >> > >> > On 28 Mar 2017, at 00:25, Andres Freund <and...@anarazel.de> wrote:

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-28 03:47:50 +0200, Petr Jelinek wrote: > On 28/03/17 03:31, Petr Jelinek wrote: > > On 27/03/17 19:01, Robert Haas wrote: > >> On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund <and...@anarazel.de> wrote: > >>> Robert, Petr, either of you plannin

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-03-28 04:12:41 +0300, Stas Kelvich wrote: > > > On 28 Mar 2017, at 00:25, Andres Freund <and...@anarazel.de> wrote: > > > > Hi, > > > > On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: > >> Ok, here it is. > > > > On a v

Re: [HACKERS] logical decoding of two-phase transactions

Hi, On 2017-03-28 00:19:29 +0300, Stas Kelvich wrote: > Ok, here it is. On a very quick skim, this doesn't seem to solve the issues around deadlocks of prepared transactions vs. catalog tables. What if the prepared transaction contains something like LOCK pg_class; (there's a lot more realistic

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-27 13:30:11 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-27 12:18:37 -0400, Tom Lane wrote: > >> My feeling at this point is that we might be better off disabling > >> the computed-goto case by default. At the ver

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-27 13:01:11 -0400, Robert Haas wrote: > On Mon, Mar 27, 2017 at 12:50 PM, Andres Freund <and...@anarazel.de> wrote: > > Robert, Petr, either of you planning to fix this (as outlined elsewhere > > in the thred)? > > Oh, I didn't realize anybody was looking to

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-16 10:13:37 +0100, Petr Jelinek wrote: > On 16/03/17 09:53, Andres Freund wrote: > > On 2017-03-16 09:40:48 +0100, Petr Jelinek wrote: > >> On 16/03/17 04:42, Andres Freund wrote: > >>> On 2017-03-15 20:28:33 -0700, Andres Freund wrote: > >>>

Re: [HACKERS] WIP: Faster Expression Processing v4

at least gcc-5/6, even without the option (largely because it avoids array bounds checks on the jump table built for the switch). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-27 11:52:05 -0400, Tom Lane wrote: > As to the point of whether it actually helps or not ... > > on gcc 6.3.1 (Fedora 25), yes it does. Seems to be one "jmp *something" > per EEO_NEXT or EEO_JUMP. > > on gcc 4.4.7 (RHEL 6), it makes things *WORSE*. We go from about half of > the

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-27 11:22:40 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-27 09:33:43 -0400, Tom Lane wrote: > >> I think it would, primarily because if we find out that some other compiler > >> spells this differently, we could h

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-27 09:33:43 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Checking for this isn't entirely pretty - see my attached attempt at > > doing so. I considered hiding > > __attribute__((optimize("no-crossjumping"))) in exec

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-25 20:59:27 -0700, Andres Freund wrote: > On 2017-03-25 23:51:45 -0400, Tom Lane wrote: > > Andres Freund <and...@anarazel.de> writes: > > > On March 25, 2017 4:56:11 PM PDT, Ants Aasma <ants.aa...@eesti.ee> wrote: > > >> I haven't had the t

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On 2017-03-23 20:35:09 +1300, Thomas Munro wrote: > Here is a new patch series responding to feedback from Peter and Andres: + +/* Per-participant shared state. */ +typedef struct SharedTuplestoreParticipant +{ + LWLock lock; Hm. No padding (ala LWLockMinimallyPadded / LWLockPadded) - but

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi, SharedBufFile allows temporary files to be created by one backend and then exported for read-only access by other backends, with clean-up managed by reference counting associated with a DSM segment. This includes changes to fd.c and buffile.c to support new kinds of temporary file. diff

Re: [HACKERS] Valgrind failures caused by multivariate stats patch

On 2017-03-26 20:38:52 +0200, Tomas Vondra wrote: > On 03/25/2017 10:10 PM, Andres Freund wrote: > ... > > ==2486== Uninitialised byte(s) found during client check request > > ==2486==at 0x1C4857: printtup (printtup.c:347) > > ==2486==by 0x401FD5: ExecutePlan (exe

[HACKERS] Remove !isTemp buffile.c code

emp - which afaics hasn't ever been used. I'd rather remove that code, before potentially (further) breaking the unused code. Any arguments against? Greetings, Andres Freund [1] https://www.postgresql.org/message-id/CAEepm=0vp18JyWa5o_=ehK1QTZrymXk3Q0NPJoSqb=tdqti...@mail.gmail.com -- Sent

Re: [HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

On 2017-03-25 20:40:23 -0700, Andres Freund wrote: > I blindly tried to fix these, let's hope that works. In a second attempt (yes, reading diffs correctly is helpful), this resolved the selinux issue. Yeha. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-25 23:51:45 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On March 25, 2017 4:56:11 PM PDT, Ants Aasma <ants.aa...@eesti.ee> wrote: > >> I haven't had the time to research this properly, but initial tests > >> show that

Re: [HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

Hi, On 2017-03-25 17:33:33 -0700, Joe Conway wrote: > On 03/25/2017 05:21 PM, Andres Freund wrote: > > On March 25, 2017 4:54:08 PM PDT, Joe Conway <m...@joeconway.com> wrote: > >>On 03/25/2017 04:45 PM, Andres Freund wrote: > >>> I think, for starters, seeing

Re: [HACKERS] WIP: Faster Expression Processing v4

On March 25, 2017 4:56:11 PM PDT, Ants Aasma <ants.aa...@eesti.ee> wrote: >On Sun, Mar 26, 2017 at 12:22 AM, Andres Freund <and...@anarazel.de> >wrote: >>> At least with current gcc (6.3.1 on Fedora 25) at -O2, >>> what I see is multiple places jumping to th

Re: [HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

On March 25, 2017 4:54:08 PM PDT, Joe Conway <m...@joeconway.com> wrote: >On 03/25/2017 04:45 PM, Andres Freund wrote: >> On 2017-03-25 16:36:03 -0700, Joe Conway wrote: >>> On 03/25/2017 04:03 PM, Andres Freund wrote: >>> > Hi Joe, >>> > >>

[HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

On 2017-03-25 16:36:03 -0700, Joe Conway wrote: > On 03/25/2017 04:03 PM, Andres Freund wrote: > > Hi Joe, > > > > > > On 2017-03-25 22:11:37 +, Andres Freund wrote: > >> Faster expression evaluation and targetlist projection. > > > > Appar

[HACKERS] Re: [COMMITTERS] pgsql: Faster expression evaluation and targetlist projection.

Hi Joe, On 2017-03-25 22:11:37 +, Andres Freund wrote: > Faster expression evaluation and targetlist projection. Apparently this broke the selinux integration somehow: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinoceros=2017-03-25%2022%3A45%3A01 Unfortunately the buildf

Re: [HACKERS] [COMMITTERS] pgsql: git rm execQual.c

On 2017-03-25 22:22:21 +, Tom Lane wrote: > git rm execQual.c > > Should have been in commit b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755, > but passing the patch back and forth as a patch seems to have dropped > that metadata. Ah, thanks. FWIW, using git style patches (git format-patch), gets

Re: [HACKERS] WIP: Faster Expression Processing v4

Might be worthwhile experimenting with setting them locally via a pragma or such. I think Aants wanted to experiment with that, too. Then there's also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 which causes some forms of computed goto (not ours I think) to be deoptimized in gcc. Greetings, Andres

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-24 17:16:15 -0400, Tom Lane wrote: > Attached is an updated patch. I believe this is committable, but > since I whacked it around quite a bit, I'm sure you'll want to look > it over first. Indeed. Points: - It's going to take a while for me to get used to execExprInterp.c - I

[HACKERS] Valgrind failures caused by multivariate stats patch

fun:ServerLoop } printttup being reached usually isn't a good signal... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] standardized backwards incompatibility tag for commits

and a bunch of other conventions for commit messages, somewhere (protected wiki page?). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WIP: Faster Expression Processing v4

hat. In contrast to the other changes you've talked about, this definitely is in the hot-path... > Also, for JIT purposes it'd still be entirely possible to compile the > slot_getsomeattrs calls in-line; you'd just be looking to a different > part of the ExprState struct to find out wha

Re: [HACKERS] [COMMITTERS] pgsql: Avoid SnapshotResetXmin() during AtEOXact_Snapshot()

On 2017-03-24 13:50:54 -0400, Robert Haas wrote: > On Fri, Mar 24, 2017 at 12:27 PM, Robert Haas wrote: > > On Fri, Mar 24, 2017 at 12:14 PM, Robert Haas wrote: > >> On Fri, Mar 24, 2017 at 10:23 AM, Simon Riggs > >> wrote: >

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-23 21:58:03 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-23 21:26:19 -0400, Tom Lane wrote: > >> Hmm, I see ... but that only works in the cases where the caller of > >> ExecBuildProjectionInfo supplied a source

Re: [HACKERS] No more libedit?! - openssl plans to switch to APL2

On 2017-03-24 02:31:47 +0100, Andreas Karlsson wrote: > On 08/01/2015 05:14 PM, Andres Freund wrote: > > According to https://www.openssl.org/blog/blog/2015/08/01/cla/ openssl > > is planning to relicense to the apache license 2.0. While APL2 is not > > compatible with GL

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-23 21:26:19 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-23 20:36:32 -0400, Tom Lane wrote: > >> The problem here is that once we drop the buffer pin, any pointers we may > >> have into on-disk data are dangling p

Re: [HACKERS] No more libedit?! - openssl plans to switch to APL2

On 2015-08-01 17:14:10 +0200, Andres Freund wrote: > According to https://www.openssl.org/blog/blog/2015/08/01/cla/ openssl > is planning to relicense to the apache license 2.0. While APL2 is not > compatible with GLP2 it *is* compatible with GPL3. Just 5 minutes later, some

Re: [HACKERS] WIP: Faster Expression Processing v4

will have to deform the whole tuple again, and that seems like a lot more likely scenario. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WIP: Faster Expression Processing v4

ch then ExecEvalScalarVar * will probably throw an error at runtime, but we leave that to it.) */ > I hope to have a fully reviewed patch to pass back to you tomorrow. > Or Saturday at the latest. Cool. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WIP: Faster Expression Processing v4

d of casewhen.value/casewhen.isnull in favor of letting CASE WHEN > expressions evaluate into the CASE's final output variable. That sounds like a sensible change (in the abstract, I obviously haven't seen your working copy). Greetings, Andres Freund -- Sent via pgsql-hackers mail

Re: [HACKERS] Privilege checks on array coercions

On 2017-03-23 15:26:51 -0400, Tom Lane wrote: > There is a test in privileges.sql (currently lines 589-625 in > privileges.out) that seems to be dependent on the fact that the > ArrayCoerceExpr logic doesn't check for EXECUTE privilege on the > per-element type coercion function if it's dealing

Re: [HACKERS] Hash support for grouping sets

On 2017-03-23 05:09:46 +, Andrew Gierth wrote: > >>>>> "Andres" == Andres Freund <and...@anarazel.de> writes: > > >> - Assert(newphase == 0 || newphase == aggstate->current_phase + 1); > >> + Assert(newphase <= 1 || ne

Re: [HACKERS] Hash support for grouping sets

On 2017-03-23 03:43:57 +, Andrew Gierth wrote: > >>>>> "Andres" == Andres Freund <and...@anarazel.de> writes: > > Andres> Changes to advance_aggregates() are, in my experience, quite > Andres> likely to have performance effec

Re: [HACKERS] WIP: Faster Expression Processing v4

bered a note about pass-by-ref arguments. fmgr/README? A note in FunctionCallInfoData's definition? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] parallel "return query" is no good

On 2017-03-23 13:03:19 -0400, Robert Haas wrote: > On Thu, Mar 23, 2017 at 12:50 PM, Robert Haas wrote: > > Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel > > plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE > > statement in a

Re: [HACKERS] Logical decoding on standby

On 2017-03-23 12:14:02 +0800, Craig Ringer wrote: > On 23 March 2017 at 09:39, Andres Freund <and...@anarazel.de> wrote: > > I still think decoding-on-standby is simply not the right approach as > > the basic/first HA approach for logical rep. It's a nice later-on >

Re: [HACKERS] Logical decoding on standby

On 2017-03-23 09:14:07 +0800, Craig Ringer wrote: > On 23 March 2017 at 07:31, Andres Freund <and...@anarazel.de> wrote: > > On 2017-03-23 06:55:53 +0800, Craig Ringer wrote: > > >> I was thinking that by disallowing snapshot use and output plugin > >> invoc

Re: [HACKERS] Hash support for grouping sets

Hi, > +/* > + * Switch to phase "newphase", which must either be 0 or 1 (to reset) or > * current_phase + 1. Juggle the tuplesorts accordingly. > */ > static void > initialize_phase(AggState *aggstate, int newphase) > { > - Assert(newphase == 0 || newphase == aggstate->current_phase +

Re: [HACKERS] Logical decoding on standby

On 2017-03-23 06:55:53 +0800, Craig Ringer wrote: > On 22 March 2017 at 21:06, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > > > On 2017-03-21 09:05:26 +0800, Craig Ringer wrote: > >> > 0002 should be doable as a whole this release, I have severe

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-22 13:15:41 -0400, Tom Lane wrote: > BTW, I'm fairly concerned by what you did in nodeTidscan.c, ie delaying > compile of the TID expressions until TidListCreate. I think that probably > fails for cases involving, eg, subplans in the expressions; we need > subplans to get linked to the

Re: [HACKERS] Logical decoding on standby

On 2017-03-22 15:59:42 +, Simon Riggs wrote: > On 22 March 2017 at 13:06, Andres Freund <and...@anarazel.de> wrote: > > >> The parts I think are important for Pg10 are: > > > >> * Ability to create logical slots on replicas > > > > Doesn't thi

Re: [HACKERS] Logical decoding on standby

On 2017-03-22 14:58:29 +, Simon Riggs wrote: > On 22 March 2017 at 13:06, Andres Freund <and...@anarazel.de> wrote: > > > But I have to admit, I've *severe* doubts about getting the whole > > infrastructure for slot creation on replica into 10. The work is far > &

Re: [HACKERS] Metadata about relation creation & full scans.

On March 22, 2017 3:54:07 PM GMT+01:00, Tom Lane <t...@sss.pgh.pa.us> wrote: >Andres Freund <and...@anarazel.de> writes: >> On 2017-03-22 10:14:14 -0400, Tom Lane wrote: >>> (2) How you gonna update this in vacuum? It cannot do a >transactional >&g

Re: [HACKERS] WIP: Faster Expression Processing v4

repareExpr or ExecFinishExpr or something along that line would > be better, but nothing is really standing out as le mot juste. Either of those work, but they don't strike me as perfect either, but I can't come up with something better (ExecReadyExprForExec()?). Greetings, Andres Freund --

Re: [HACKERS] Metadata about relation creation & full scans.

On 2017-03-22 10:14:14 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I propose that for each pg_class entry we start to keep the following > > additional metadata: > > - CATALOG_VERSION_NO at relation creation > > - PG

Re: [HACKERS] Logical decoding on standby

ity to advance (via feedback or via SQL function) - no need to > actually decode and call output plugins at al That pretty much requires decoding, otherwise you really don't know how much WAL you have to retain. > * Ability to drop logical slots on replicas That shouldn't actually requir

[HACKERS] Metadata about relation creation & full scans.

might have originated has made that harder. I'd suggest adding such fields into the CATALOG_VARLEN bit of pg_class, there's no point in having the information in relcache and such. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

l the rows is > > particularly unrealistic. > > > Ok. But those who update 10M rows in a single transaction, would they > really notice 5-10% variation? Yes. It's very common in ETL, and that's quite performance sensitive. Greetings, Andres Freund -- Sent via pgsql-hackers mai

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

iven that more than one place run into the issue with deforming cost via heap_*, that seems like something we're going to have to do. Additionally the patches I had for JITed deforming all integrated at the slot layer, so it'd be a good thing from that angle as well. Deforming all columns

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-20 16:06:27 -0400, Tom Lane wrote: > ... is there a reason why resultnum for EEOP_ASSIGN_* steps is declared > size_t and not just int? Since it's an array index, and one that > certainly can't be bigger than AttrNumber, that seems rather confusing. Not that I can see, no. I guess I

Re: [HACKERS] [COMMITTERS] pgsql: Add missing support for new node fields

Hi, On 2017-03-21 07:22:57 +0100, Fabien COELHO wrote: > > Add missing support for new node fields > > > > Commit b6fb534f added two new node fields but neglected to add copy and > > comparison support for them, Mea culpa, should have checked for that. > > I've been annoyed by these stupid

Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

ink that expectation has anything to do with being anti-test. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Logical decoding on standby

Hi, Have you checked how high the overhead of XLogReadDetermineTimeline is? A non-local function call, especially into a different translation-unit (no partial inlining), for every single page might end up being noticeable. That's fine in the cases it actually adds functionality, but for a

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-19 23:55:50 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I've been pondering if we can't entirely get rid of CaseTest etc, the > > amount of hackery required seems not like a good thing. One way I'd > > prototyped was to r

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-16 11:15:16 -0400, Tom Lane wrote: > The thing that actually made the ExecEvalCase code into a bug was that > we were using ExprContext-level fields to store the current caseValue, > allowing aliasing to occur across nested CASEs. I think that in > this implementation, it ought

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

n the git style, that we could easily expand over time, without hitting new conflicts. I'd even consider a '/usr/bin/pgsql' that has commands for all our binaries a considerable improvement in the long term. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@pos

[HACKERS] Introduce expression initialization hook?

Hi, It looks we're creeping towards agreement in http://archives.postgresql.org/message-id/20161206034955.bh33paeralxbtluv%40alap3.anarazel.de It'd be fairly easy to add a hook in its ExecInstantiateExpr(), which'd allow extensions to provide newer (presumably faster) ways to evaluate

Re: [HACKERS] Candidate for local inline function?

cro versus a static inline function, at least > in the cases I checked. I'm absolutely not against changing this to an inline function, but I'd prefer if that code weren't touched quite right now, there's a large pending patch of mine in the area. If you don't mind, I'll just include the change there,

Re: [HACKERS] WIP: Faster Expression Processing v4

currently has as out-of-line one-time checks > in the new code. We can revisit that later, but time grows short for > v10. I would much rather have a solid version of 0004 and not 0001, > than not have anything for v10 because we spent too much time dealing > with adding new dependenc

Re: [HACKERS] [COMMITTERS] pgsql: Use asynchronous connect API in libpqwalreceiver

find a fix other than adding > WL_TIMEOUT and short timeout to WaitLatchOrSocket (it does wait a very > long time on the WaitLatchOrSocket otherwise before failing). Hm. Could you use process explorer or such to see the exact events happening? Seing that might help us to nail this down. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Size vs size_t

On 2017-03-16 17:24:17 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Mar 16, 2017 at 5:01 PM, Andres Freund <and...@anarazel.de> wrote: > >> On 2017-03-16 16:59:29 -0400, Robert Haas wrote: > >>> I guess I assumed that

Re: [HACKERS] Size vs size_t

his case, defining Size in the first place was a bad call on behalf of the project. It gains us absolutely nothing, but makes it harder to read for people that don't know PG all that well. I think we should slowly phase out Size usage, at least in new code. Greetings, Andres Freund -- Sent via

Re: [HACKERS] logical replication launcher crash on buildfarm

on every platform? Alternatively we can just hardcode a bunch of bgw_function_name values that are matched to specific functions if bgw_library_name is NULL - I suspect that'd be the easiest / least worrysome portability-wise. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-16 09:40:48 +0100, Petr Jelinek wrote: > On 16/03/17 04:42, Andres Freund wrote: > > On 2017-03-15 20:28:33 -0700, Andres Freund wrote: > >> Hi, > >> > >> I just unstuck a bunch of my buildfarm animals. That triggered some > >> spurious

[HACKERS] Quals not pushed down into lateral

nytime soon, but I thought it'd be useful to have a searchable reference point about the topic. If somebody wants to work on it... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-16 09:40:48 +0100, Petr Jelinek wrote: > On 16/03/17 04:42, Andres Freund wrote: > > On 2017-03-15 20:28:33 -0700, Andres Freund wrote: > >> Hi, > >> > >> I just unstuck a bunch of my buildfarm animals. That triggered some > >> spurious

Re: [HACKERS] logical replication launcher crash on buildfarm

On 2017-03-15 20:28:33 -0700, Andres Freund wrote: > Hi, > > I just unstuck a bunch of my buildfarm animals. That triggered some > spurious failures (on piculet, calliphoridae, mylodon), but also one > that doesn't really look like that: > https://buildfarm.postgresql.org/cgi-

[HACKERS] logical replication launcher crash on buildfarm

while till it's at that animal/branch again, otherwise I'd not have mentioned this. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Microvacuum support for Hash Index

On 2017-03-15 16:31:11 -0400, Robert Haas wrote: > On Wed, Mar 15, 2017 at 3:54 PM, Ashutosh Sharma > wrote: > > Changed as per suggestions. Attached v9 patch. Thanks. > > Wow, when do you sleep? I think that applies to a bunch of people, including yourself ;) -- Sent

Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

On 2017-03-15 11:20:53 -0400, Stephen Frost wrote: > Greetings Hari Babu, > > * Haribabu Kommi (kommi.harib...@gmail.com) wrote: > > On Mon, Mar 13, 2017 at 6:52 AM, Stephen Frost wrote: > > > And, naturally, re-reading the email as it hit the list made me realize > > > that

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-15 20:09:03 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > [ new patches ] > > I've started to look at 0004, and the first conclusion I've come to > is that it's *direly* short of documentation. To the point that I'd &

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 18:48:28 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-15 18:16:57 -0400, Tom Lane wrote: > >> [ scratches head... ] What deforming logic do you think I'm proposing > >> removing? > > > I th

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 18:16:57 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-15 17:33:46 -0400, Tom Lane wrote: > >> We could make the planner mark each table scan node with the highest > >> column number that the plan w

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 17:33:46 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-15 16:07:14 -0400, Tom Lane wrote: > >> As for ExecHashGetHashValue, it's most likely going to be working from > >> virtual tuples passed up to t

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 16:07:14 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2017-03-15 15:41:22 -0400, Tom Lane wrote: > >> Color me dubious. Which specific other places have you got in mind, and > >> do they have expression trees at hand t

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-15 15:41:22 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On March 15, 2017 12:33:28 PM PDT, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> So for my money, you should drop 0002 altogether and just have 0004 > >> remove get_la

Re: [HACKERS] WIP: Faster Expression Processing v4

On March 15, 2017 12:33:28 PM PDT, Tom Lane <t...@sss.pgh.pa.us> wrote: >Andres Freund <and...@anarazel.de> writes: >> [ latest patches ] > >I looked through 0002-Make-get_last_attnums-more-generic.patch. >So for my money, you should drop 0002 altoget

Re: [HACKERS] Leftover invalidation handling in RemoveRelations

Hi, On 2017-03-15 14:46:22 -0400, Robert Haas wrote: > On Wed, Mar 15, 2017 at 2:40 PM, Andres Freund <and...@anarazel.de> wrote: > Yeah, I don't think that would hurt anything. > > (I'm not sure it'll help anything either - the overhead of an extra > AcceptInvalidationMes

[HACKERS] Leftover invalidation handling in RemoveRelations

oks like this was left there in the course of http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2ad36c4e44c8b513f6155656e1b7a8d26715bb94 ISTM AcceptInvalidationMessages() and preceding comment should just be removed? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] [COMMITTERS] pgsql: Improve isolation tests infrastructure.

Hi Peter, All, On 2017-03-14 23:10:19 +, Andres Freund wrote: > Improve isolation tests infrastructure. There's: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=frogmouth=2017-03-15%2012%3A32%3A45 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=narwhal=2017-03-15%2005%3

<    5   6   7   8   9   10   11   12   13   14   >