Re: [HACKERS] [POC] A better way to expand hash indexes.

Thanks, Amit for the review. On Sat, Mar 25, 2017 at 7:03 PM, Amit Kapila wrote: > > I think one-dimensional patch has fewer places to touch, so that looks > better to me. However, I think there is still hard coding and > assumptions in code which we should try to improve. Great!, I will continu

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

On Sat, Mar 25, 2017 at 7:56 PM, Thomas Munro wrote: > On Sun, Mar 26, 2017 at 1:53 PM, Peter Geoghegan wrote: >> ISTM that your patch now shares a quality with parallel tuplesort: You >> may now hold files open after an unlink() of the original link/path >> that they were opened using. As Robert

Re: [HACKERS] Remove !isTemp buffile.c code

On Sat, Mar 25, 2017 at 10:25 PM, Andres Freund wrote: > buffile.c currently has a fair amount of code dependant on > BufFile->isTemp - which afaics hasn't ever been used. I'd rather remove > that code, before potentially (further) breaking the unused code. I think this is a good idea, but then

[HACKERS] Remove !isTemp buffile.c code

Hi, A nearby thread [1], does some work on buffile.c. Amongst others it renames isTemp to something else (not sure yet why - the new name is about as apt as before), but that's not really what I want to talk about here. buffile.c currently has a fair amount of code dependant on BufFile->isTemp -

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.org) To make

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-25 23:51:45 -0400, Tom Lane wrote: > Andres Freund writes: > > On March 25, 2017 4:56:11 PM PDT, Ants Aasma wrote: > >> I haven't had the time to research this properly, but initial tests > >> show that with GCC 6.2 adding > >> > >> #pragma GCC optimize ("no-crossjumping") > >> > >>

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On March 25, 2017 4:56:11 PM PDT, Ants Aasma wrote: >> I haven't had the time to research this properly, but initial tests >> show that with GCC 6.2 adding >> >> #pragma GCC optimize ("no-crossjumping") >> >> fixes merging of the op tail jumps. >> >> Some quick and dirt

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 wrote: > >>On 03/25/2017 04:45 PM, Andres Freund wrote: > >>> I think, for starters, seeing regression.diffs from sepgsql would be > >>> useful. Mig

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

On Sat, Mar 25, 2017 at 11:24 PM, Pavan Deolasee wrote: > > On Sat, 25 Mar 2017 at 11:03 PM, Peter Geoghegan wrote: >> >> On Sat, Mar 25, 2017 at 12:54 AM, Amit Kapila >> wrote: >> > I am not sure how do you want to binary compare two datums, if you are >> > thinking datumIsEqual(), that won't w

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

On Sun, Mar 26, 2017 at 1:53 PM, Peter Geoghegan wrote: > ISTM that your patch now shares a quality with parallel tuplesort: You > may now hold files open after an unlink() of the original link/path > that they were opened using. As Robert pointed out when discussing > parallel tuplesort earlier i

Re: [HACKERS] free space map and visibility map

On Thu, Mar 23, 2017 at 7:01 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > At Wed, 22 Mar 2017 02:15:26 +0900, Masahiko Sawada > wrote in gmail.com> > > On Mon, Mar 20, 2017 at 11:28 PM, Robert Haas > wrote: > > > On Sat, Mar 18, 2017 at 5:42 PM, Jeff Janes > wrote: > > >>

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Thanks for your time. I've updated the proposal according to your comments. But I am still wondering that can you review it for a double-check to make sure I've made everything clear? You can read my replies for reference. > -Original Messages- > From: "Kevin Grittner" > Sent Time: 20

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Sat, Mar 25, 2017 at 11:46 PM, Peter Eisentraut wrote: > On 3/13/17 09:15, Mithun Cy wrote: >> A. launch_autoprewarm_dump() RETURNS int4 >> This is a SQL callable function to launch the autoprewarm worker to >> dump the buffer pool information at regular interval. In a server, we >> can only ru

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

On Thu, Mar 23, 2017 at 12:35 AM, Thomas Munro wrote: > Thanks. I really appreciate your patience with the resource > management stuff I had failed to think through. It's a surprisingly difficult problem, that almost requires prototyping just to explain. No need to apologize. This is the process

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

On 03/25/2017 05:21 PM, Andres Freund wrote: > On March 25, 2017 4:54:08 PM PDT, Joe Conway wrote: >>On 03/25/2017 04:45 PM, Andres Freund wrote: >>> I think, for starters, seeing regression.diffs from sepgsql would be >>> useful. Might already clear up what's the issue. >> >>I went looking, and

Re: [HACKERS] WIP: Faster Expression Processing v4

On March 25, 2017 4:56:11 PM PDT, Ants Aasma wrote: >On Sun, Mar 26, 2017 at 12:22 AM, Andres Freund >wrote: >>> At least with current gcc (6.3.1 on Fedora 25) at -O2, >>> what I see is multiple places jumping to the same indirect jump >>> instruction :-(. It's not a total disaster: as best I

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

On March 25, 2017 4:54:08 PM PDT, Joe Conway 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, >>> > >>> > >>> > On 2017-03-25 22:11:37 +, Andres Freund wrote: >>> >> Faster

Re: [HACKERS] WIP: Faster Expression Processing v4

On Sun, Mar 26, 2017 at 12:22 AM, Andres Freund wrote: >> At least with current gcc (6.3.1 on Fedora 25) at -O2, >> what I see is multiple places jumping to the same indirect jump >> instruction :-(. It's not a total disaster: as best I can tell, all the >> uses of EEO_JUMP remain distinct. But

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

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, >> > >> > >> > On 2017-03-25 22:11:37 +, Andres Freund wrote: >> >> Faster expression evaluation and targetlist projection. >> > >> > Ap

[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. > > > > Apparently this broke the selinux integration somehow: >

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

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. > > Apparently this broke the selinux integration somehow: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinocer

[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&dt=2017-03-25%2022%3A45%3A01 Unfortunately the buildfarm

[HACKERS] Small doc fix for xmltable

Hi, In the devel docs for xmltable there should be a comma after XMLNAMESPACES() Groeten, Arjen diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index ba6f8dd..1180385 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -10504,7 +10504,7 @@ SELECT xpath_exists('/my:a

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 ri

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-25 12:22:15 -0400, Tom Lane wrote: > More random musing ... have you considered making the jump-target fields > in expressions be relative rather than absolute indexes? That is, > EEO_JUMP would look like > > op += (stepno); \ > EEO_DISPATCH(); \ > > instea

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > - The !caseExpr->defresult result branch is currently unreachable (and > its equivalent was before the patch) because transformCaseExpr() > generates a default expression. I'm inclined to replace the dead code > with an assertion. Any reason not to do that? Ah-hah.

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

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

I wrote: > It doesn't seem to be a platform-specific problem: I can duplicate the > failure here by applying same settings mandrill uses, ie build with > -DRANDOMIZE_ALLOCATED_MEMORY and set force_parallel_mode = regress. Oh ... scratch that: you don't even need -DRANDOMIZE_ALLOCATED_MEMORY. For s

Re: [HACKERS] [COMMITTERS] pgsql: Improve access to parallel query from procedural languages.

Robert Haas writes: > Improve access to parallel query from procedural languages. Mandrill has been failing since this patch went in, eg https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2017-03-25%2021%3A34%3A08 It doesn't seem to be a platform-specific problem: I can duplica

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

Andres Freund writes: > I just tried to run valgrind before pushing my expression evaluation > work, but that triggers independent failures: FWIW, I just now finished valgrinding the regression tests on 457a44487 plus the expression patch, and it looked good. So these failures are definitely ind

Re: [HACKERS] LWLock optimization for multicore Power machines

On Sat, Mar 25, 2017 at 11:32 PM, Tom Lane wrote: > Alexander Korotkov writes: > > I moved PPC implementation of pg_atomic_fetch_mask_add_u32() into > > port/atomics/arch-ppc.h. I also had to declare pg_atomic_uint32 there to > > satisfy usage of this type as argument > > of pg_atomic_fetch_mas

[HACKERS] Valgrind failures caused by multivariate stats patch

Hi, I just tried to run valgrind before pushing my expression evaluation work, but that triggers independent failures: ==2486== Uninitialised byte(s) found during client check request ==2486==at 0x5B56B9: PageAddItemExtended (bufpage.c:329) ==2486==by 0x225E14: RelationPutHeapTuple (hio.c

Re: [HACKERS] LWLock optimization for multicore Power machines

Alexander Korotkov writes: > I moved PPC implementation of pg_atomic_fetch_mask_add_u32() into > port/atomics/arch-ppc.h. I also had to declare pg_atomic_uint32 there to > satisfy usage of this type as argument > of pg_atomic_fetch_mask_add_u32_impl(). Hm, you did something wrong there, because

Re: [HACKERS] standardized backwards incompatibility tag for commits

Andres Freund writes: > Seems like it'd be good to standardize how we're declaring that a commit > contains backwards incompatible changes. I've seen > - 'BACKWARDS INCOMPATIBLE CHANGE' > - 'BACKWARD INCOMPATIBILITY' > - a lot of free-flow text annotations like "as a > backward-incompatibility"

Re: [HACKERS] LWLock optimization for multicore Power machines

On Sat, Mar 25, 2017 at 8:44 PM, Tom Lane wrote: > Alexander Korotkov writes: > > [ lwlock-power-3.patch ] > > I experimented with this patch a bit. I can't offer help on testing it > on large PPC machines, but I can report that it breaks the build on > Apple PPC machines, apparently because of

[HACKERS] standardized backwards incompatibility tag for commits

Hi, Seems like it'd be good to standardize how we're declaring that a commit contains backwards incompatible changes. I've seen - 'BACKWARDS INCOMPATIBLE CHANGE' - 'BACKWARD INCOMPATIBILITY' - a lot of free-flow text annotations like "as a backward-incompatibility", "This makes a backwards-inco

Re: [HACKERS] Proposal : For Auto-Prewarm.

On 3/13/17 09:15, Mithun Cy wrote: > A. launch_autoprewarm_dump() RETURNS int4 > This is a SQL callable function to launch the autoprewarm worker to > dump the buffer pool information at regular interval. In a server, we > can only run one autoprewarm worker so if a worker sees another > existing w

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

On Sat, 25 Mar 2017 at 11:03 PM, Peter Geoghegan wrote: > On Sat, Mar 25, 2017 at 12:54 AM, Amit Kapila > wrote: > > I am not sure how do you want to binary compare two datums, if you are > > thinking datumIsEqual(), that won't work. I think you need to use > > datatype specific compare functio

Re: [HACKERS] LWLock optimization for multicore Power machines

Alexander Korotkov writes: > [ lwlock-power-3.patch ] I experimented with this patch a bit. I can't offer help on testing it on large PPC machines, but I can report that it breaks the build on Apple PPC machines, apparently because of nonstandard assembly syntax. I get "Parameter syntax error" o

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

On Sat, Mar 25, 2017 at 12:54 AM, Amit Kapila wrote: > I am not sure how do you want to binary compare two datums, if you are > thinking datumIsEqual(), that won't work. I think you need to use > datatype specific compare function something like what we do in > _bt_compare(). How will that inter

Re: [HACKERS] [COMMITTERS] pgsql: Allow vacuums to report oldestxmin

On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao wrote: > On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada wrote: >> On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs wrote: >>> Allow vacuums to report oldestxmin >>> >>> Allow VACUUM and Autovacuum to report the oldestxmin value they >>> used while cleani

Re: [HACKERS] increasing the default WAL segment size

At this point, I suggest splitting this patch up into several potentially less controversial pieces. One big piece is that we currently don't support segment sizes larger than 64 GB, for various internal arithmetic reasons. Your patch appears to address that. So I suggest isolating that. Assumi

Re: [HACKERS] increasing the default WAL segment size

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/24/17 08:18, Stephen Frost wrote: > > Beyond that, this also bakes in an assumption that we would then require > > access to a database > > That is a good point, but then any change to the naming whatsoever will > create t

Re: [HACKERS] LWLock optimization for multicore Power machines

On Thu, Mar 16, 2017 at 8:35 PM, David Steele wrote: > On 2/21/17 9:54 AM, Bernd Helmle wrote: > > Am Dienstag, den 14.02.2017, 15:53 +0300 schrieb Alexander Korotkov: > >> +1 > >> And you could try to use pg_wait_sampling > >> to sampling of wait

Re: [HACKERS] [COMMITTERS] pgsql: Allow vacuums to report oldestxmin

On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada wrote: > On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs wrote: >> Allow vacuums to report oldestxmin >> >> Allow VACUUM and Autovacuum to report the oldestxmin value they >> used while cleaning tables, helping to make better sense out of >> the other

Re: [HACKERS] Monitoring roles patch

Hi > On 25 Mar 2017, at 15:55, Stephen Frost wrote: > > Robert, > > * Robert Haas (robertmh...@gmail.com) wrote: >>> On Fri, Mar 24, 2017 at 12:46 PM, Dave Page wrote: On Fri, Mar 24, 2017 at 4:24 PM, Robert Haas wrote: That's possible, but it really depends on the tool, not on core

Re: [HACKERS] increasing the default WAL segment size

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/24/17 19:13, David Steele wrote: > > Behavior for the current default of 16MB is unchanged, and all other > > sizes go through a logical progression. > > Just at a glance, without analyzing the math behind it, this scheme

Re: [HACKERS] WIP: Faster Expression Processing v4

More random musing ... have you considered making the jump-target fields in expressions be relative rather than absolute indexes? That is, EEO_JUMP would look like op += (stepno); \ EEO_DISPATCH(); \ instead of op = &state->steps[stepno]; \

Re: [HACKERS] Monitoring roles patch

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Mar 24, 2017 at 8:30 AM, Stephen Frost wrote: > >> But why not do it with GRANTs in the first place then? > > > > This is akin to asking why do we need GRANT ALL and ALTER DEFAULT PRIVs. I wasn't very clear with my thinking as to why

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On Sat, Mar 25, 2017 at 7:01 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/25/17 09:01, David Rowley wrote: > > On 25 March 2017 at 23:09, Rushabh Lathia > wrote: > >> Also another point which I think we should fix is, when someone set > >> max_parallel_workers = 0, we sh

Re: [HACKERS] Report the number of skipped frozen pages by manual VACUUM

On Sat, Mar 25, 2017 at 2:42 AM, Fujii Masao wrote: > On Thu, Mar 23, 2017 at 4:28 AM, Fujii Masao wrote: >> On Wed, Mar 15, 2017 at 7:51 PM, Masahiko Sawada >> wrote: >>> On Wed, Mar 15, 2017 at 1:09 PM, Yugo Nagata wrote: On Fri, 10 Mar 2017 20:08:42 +0900 Masahiko Sawada wrote: >

Re: [HACKERS] PL/Python: Add cursor and execute methods to plan object

Jim Nasby writes: > On 2/25/17 10:27 AM, Peter Eisentraut wrote: >> So I'm also wondering here which style people prefer so >> I can implement it there. > > I think the more OO style is definitely better. I expect it would > simplify the code as well. I'm not a Python person, but I'd argue that

Re: [HACKERS] Monitoring roles patch

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Mar 24, 2017 at 12:46 PM, Dave Page wrote: > > On Fri, Mar 24, 2017 at 4:24 PM, Robert Haas wrote: > >> That's possible, but it really depends on the tool, not on core > >> PostgreSQL. The tool should be the one providing the script

Re: [HACKERS] increasing the default WAL segment size

On 3/24/17 08:18, Stephen Frost wrote: > Peter, > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> There is a function for that. > [...] >> There is not a function for that, but there could be one. > > I'm not sure you've really considered what you're suggesting here. Create a s

Re: [HACKERS] increasing the default WAL segment size

On 3/24/17 19:13, David Steele wrote: > Behavior for the current default of 16MB is unchanged, and all other > sizes go through a logical progression. Just at a glance, without analyzing the math behind it, this scheme seems super confusing. > > 1GB: > 00010040 > 0001000

Re: [HACKERS] dsm.c API tweak

Thomas Munro wrote: > I'd word this slightly differently: > > + * If there is a CurrentResourceOwner, the new segment is born unpinned and > the > + * resource owner is in charge of destroying it (and will be blamed if it > + * doesn't). If there's no current resource owner, then the segment st

Re: [HACKERS] Logical decoding on standby

On 24 March 2017 at 06:23, Craig Ringer wrote: > On 23 March 2017 at 17:44, Craig Ringer wrote: > > Minor update to catalog_xmin walsender patch to fix failure to > parenthesize definition of PROCARRAY_PROC_FLAGS_MASK . > > This one's ready to go. Working on drop slots on DB drop now. Committed.

Re: [HACKERS] [POC] A better way to expand hash indexes.

On Sat, Mar 25, 2017 at 10:13 AM, Mithun Cy wrote: > On Tue, Mar 21, 2017 at 8:16 AM, Amit Kapila wrote: >> Sure, I was telling you based on that. If you are implicitly treating >> it as 2-dimensional array, it might be easier to compute the array >>offsets. > > I think calculating spares offset

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On 3/25/17 09:01, David Rowley wrote: > On 25 March 2017 at 23:09, Rushabh Lathia wrote: >> Also another point which I think we should fix is, when someone set >> max_parallel_workers = 0, we should also set the >> max_parallel_workers_per_gather >> to zero. So that way it we can avoid generating

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On 26 March 2017 at 00:17, Amit Kapila wrote: > On Sat, Mar 25, 2017 at 6:31 PM, David Rowley > wrote: >> On 25 March 2017 at 23:09, Rushabh Lathia wrote: >>> Also another point which I think we should fix is, when someone set >>> max_parallel_workers = 0, we should also set the >>> max_parallel

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On Sat, Mar 25, 2017 at 6:31 PM, David Rowley wrote: > On 25 March 2017 at 23:09, Rushabh Lathia wrote: >> Also another point which I think we should fix is, when someone set >> max_parallel_workers = 0, we should also set the >> max_parallel_workers_per_gather >> to zero. So that way it we can a

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On 25 March 2017 at 23:09, Rushabh Lathia wrote: > Also another point which I think we should fix is, when someone set > max_parallel_workers = 0, we should also set the > max_parallel_workers_per_gather > to zero. So that way it we can avoid generating the gather path with > max_parallel_worker =

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 24 March 2017 at 23:21, David Steele wrote: > Hi Vaishnavi, > > On 3/19/17 9:32 PM, Vaishnavi Prabakaran wrote: >> >> On Fri, Mar 17, 2017 at 12:37 AM, Daniel Verite > >> Please let me know if you think this is not enough but wanted to update >> section 33.6 also? > > > Daniel, any input here?

Re: [HACKERS] New CORRESPONDING clause design

> > > I took a quick look through this and noted that it fails to touch > ruleutils.c, which means that dumping of views containing CORRESPONDING > certainly doesn't work. > fixed > Also, the changes in parser/analyze.c seem rather massive and > correspondingly hard to review. Is it possible to r

Re: [HACKERS] crashes due to setting max_parallel_workers=0

Thanks Tomas for reporting issue and Thanks David for working on this. I can see the problem in GatherMerge, specially when nworkers_launched is zero. I will look into this issue and will post a fix for the same. Also another point which I think we should fix is, when someone set max_parallel_wor

[HACKERS] PDF build is broken

Hi, I can't build PDFs with latest snapshot tarball: $ make postgres-A4.pdf { \ echo ""; \ echo ""; \ } > version.sgml '/usr/bin/perl' ./mk_feature_tables.pl YES ../../../src/backend/catalog/sql_feature_pa

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

>> >> +1. If we consider some more names for that column then probably one >> alternative could be "empty pages". > > Yeah, but I think "unused" might be better. Because a page could be > in use (as an overflow page or primary bucket page) and still be > empty. > >

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Sat, Mar 25, 2017 at 6:04 PM, Amit Kapila wrote: > On Tue, Mar 21, 2017 at 5:51 PM, Dilip Kumar wrote: >> On Tue, Mar 21, 2017 at 4:47 PM, Thomas Munro >> wrote: >>> I noticed a failure in the inet.sql test while running the regression >>> tests with parallelism cranked up, and can reproduce

Re: [HACKERS] crashes due to setting max_parallel_workers=0

On 25 March 2017 at 13:10, Tomas Vondra wrote: > while working on a patch I ran into some crashes that seem to be caused by > inconsistent handling of max_parallel_workers - queries still seem to be > planned with parallel plans enabled, but then crash at execution. > > The attached script reprodu

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

On Fri, Mar 24, 2017 at 9:23 PM, Robert Haas wrote: > On Thu, Mar 23, 2017 at 7:29 AM, Michael Paquier > wrote: >> On Thu, Mar 23, 2017 at 8:19 PM, Kuntal Ghosh >> wrote: >>> Hence, to be consistent with others, bgworker processes can be >>> initialized from BackgroundWorkerInitializeConnectionB

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

On Sat, Mar 25, 2017 at 12:33 PM, Ashutosh Sharma wrote: > On Sat, Mar 25, 2017 at 11:02 AM, Amit Kapila wrote: >> On Thu, Mar 23, 2017 at 11:24 PM, Ashutosh Sharma >> wrote: >>> Hi, >>> >>> On Tue, Feb 7, 2017 at 9:23 AM, Robert Haas wrote: On Mon, Feb 6, 2017 at 10:40 PM, Amit Kapila

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

On Fri, Mar 24, 2017 at 11:49 PM, Pavan Deolasee wrote: > > > On Fri, Mar 24, 2017 at 6:46 PM, Amit Kapila > wrote: >> >> >> >> I was worried for the case if the index is created non-default >> collation, will the datumIsEqual() suffice the need. Now again >> thinking about it, I think it will b

Re: [HACKERS] comments in hash_alloc_buckets

>> While working on - [1], I realised that the following comments in >> _hash_alloc_buckets() needs to be corrected. >> >> /* >> * Initialize the freed overflow page. Just zeroing the page won't work, >> * See _hash_freeovflpage for similar usage. >> */ >> _hash_pageinit(pag

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

On Sat, Mar 25, 2017 at 11:02 AM, Amit Kapila wrote: > On Thu, Mar 23, 2017 at 11:24 PM, Ashutosh Sharma > wrote: >> Hi, >> >> On Tue, Feb 7, 2017 at 9:23 AM, Robert Haas wrote: >>> On Mon, Feb 6, 2017 at 10:40 PM, Amit Kapila >>> wrote: > Maybe we should call them "unused pages". >>