[HACKERS] Building with MinGW

Has anyone had success following the instructions at https://wiki.postgresql.org/wiki/Building_With_MinGW#Installing_Git recently? I've followed the instructions to set up the build environment on a Windows box, and I can't build from git. I can from the nightly tarball. So I think the most

Re: [HACKERS] PATCH: use foreign keys to improve join estimates v1

On 26 September 2015 at 01:57, Tomas Vondra wrote: > Hi, > > On 09/25/2015 03:39 AM, David Rowley wrote: > >> I looked at this again, and I'm not all that sure it's possible to >> > assume that 1.0 / is valid when there's more than one >> relation at either side of

Re: [HACKERS] pg_dump LOCK TABLE ONLY question

=?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes: > I'm running pg_dump constrained to one schema. It appears that pg_dump runs > "LOCK TABLE %s IN ACCESS SHARE MODE" for each table. > Naturally it makes sense, but... > This schema has a table that serves as parent

Re: [HACKERS] BRIN indexes for MAX, MIN, ORDER BY?

Alvaro Herrera writes: > Gavin Wahl wrote: >> It seems trivial to accelerate a MAX or MIN query with a BRIN index. You >> just find the page range with the largest/smallest value, and then only >> scan that one. Would that be hard to implement? I'm interested in working

Re: [HACKERS] Rework the way multixact truncations work

On 2015-09-27 14:21:08 -0500, Jim Nasby wrote: > IMHO doing just a log of something this serious; it should at least be a > WARNING. In postgres LOG, somewhat confusingly, is more severe than WARNING. > I think the concern about upgrading a replica before the master is valid; is > there some way

Re: [HACKERS] BRIN indexes for MAX, MIN, ORDER BY?

Gavin Wahl wrote: > It seems trivial to accelerate a MAX or MIN query with a BRIN index. You > just find the page range with the largest/smallest value, and then only > scan that one. Would that be hard to implement? I'm interested in working > on it if someone can give me some pointers. I think

[HACKERS] BRIN indexes for MAX, MIN, ORDER BY?

It seems trivial to accelerate a MAX or MIN query with a BRIN index. You just find the page range with the largest/smallest value, and then only scan that one. Would that be hard to implement? I'm interested in working on it if someone can give me some pointers. Somewhat harder but still possible

Re: [HACKERS] BRIN indexes for MAX, MIN, ORDER BY?

On Mon, Sep 28, 2015 at 9:58 AM, Gavin Wahl wrote: > It seems trivial to accelerate a MAX or MIN query with a BRIN index. You > just find the page range with the largest/smallest value, and then only scan > that one. You might need to scan more than that if you don't find

Re: [HACKERS] Building with MinGW

On 09/27/2015 02:11 PM, Jeff Janes wrote: Has anyone had success following the instructions at https://wiki.postgresql.org/wiki/Building_With_MinGW#Installing_Git recently? I've followed the instructions to set up the build environment on a Windows box, and I can't build from git. I can

Re: [HACKERS] [PROPOSAL] Effective storage of duplicates in B-tree index.

On Thu, Sep 3, 2015 at 8:35 AM, Anastasia Lubennikova wrote: >> * Since everything is aligned within B-Tree, it's probably worth >> considering the alignment boundaries when doing prefix compression, if >> you want to go that way. We can probably imagine a world

Re: [HACKERS] Rework the way multixact truncations work

On 9/23/15 1:48 PM, Andres Freund wrote: Honestly, I wonder whether this message >ereport(LOG, >(errmsg("performing legacy multixact truncation"), > errdetail("Legacy truncations are sometimes performed

Re: [HACKERS] [PROPOSAL] Effective storage of duplicates in B-tree index.

On Sun, Sep 27, 2015 at 4:11 PM, Peter Geoghegan wrote: > Debugging this stuff is sometimes like keyhole surgery. If you could > just see at/get to the structure that you care about, it would be 10 > times easier. Hopefully this tool makes it easier to identify problems. I

Re: [HACKERS] BRIN indexes for MAX, MIN, ORDER BY?

> Yeah. I would urgently recommend that people *not* try to build new > things like planagg.c right now. A large part of the point of upper > planner path-ification is to have a less grotty way of dealing with > things like specialized aggregate implementations. Ok. I will wait and ask again

[HACKERS] pg_xlogdump and .partial files

The pg_xlogdump man page states that it cannot read .partial WAL files and that they need to be renamed. It seems to me with about the same number of lines we could just make it accept those files, no? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

[HACKERS] Patch: Revised documentation on base backups

On 09/28/2015 06:33 AM, Michael Paquier wrote: > On Sun, Sep 27, 2015 at 11:27 AM, Amir Rohan wrote: >> Further editing. See attached V3. > > I think that you should consider adding this patch to the next commit > fest so as we do not lose track of it: > https://commitfest.postgresql.org/7/ >

Re: [HACKERS] pg_xlogdump and .partial files

On Mon, Sep 28, 2015 at 9:47 AM, Peter Eisentraut wrote: > The pg_xlogdump man page states that it cannot read .partial WAL files > and that they need to be renamed. It seems to me with about the same > number of lines we could just make it accept those files, no? FWIW, the

Re: [HACKERS] Patch: Optimize memory allocation in function 'bringetbitmap'

Jinyu Zhang wrote: > > BRIN Scan: Optimize memory allocation in function 'bringetbitmap'. > We can allocate memory for some pointer before do long loop instead of > allocating > memory in long loop. > > Before optimizing code (warm run) > postgres=# select count(*) from lineitem where

Re: [HACKERS] On-demand running query plans using auto_explain and signals

2015-09-25 19:13 GMT+02:00 Shulgin, Oleksandr : > > > Some problems: > > There is a potential problem with the limited total number of DSM > segments: it is reserved in a way to only allow 2 per backend (on average) > and 64 additional per server, so if you run with

[HACKERS] BRIN Scan: Optimize memory allocation in function 'bringetbitmap'

BRIN Scan: Optimize memory allocation in function 'bringetbitmap'. We can allocate memory for some pointer before do long loop instead of allocating memory in long loop. Before optimizing code (warm run) postgres=# select count(*) from lineitem where l_orderkey=1; count --- 6 (1 row)

[HACKERS] Patch: Optimize memory allocation in function 'bringetbitmap'

BRIN Scan: Optimize memory allocation in function 'bringetbitmap'. We can allocate memory for some pointer before do long loop instead of allocating memory in long loop. Before optimizing code (warm run) postgres=# select count(*) from lineitem where l_orderkey=1; count --- 6 (1 row)

[HACKERS] pg_dump LOCK TABLE ONLY question

Hi. I'm running pg_dump constrained to one schema. It appears that pg_dump runs "LOCK TABLE %s IN ACCESS SHARE MODE" for each table. Naturally it makes sense, but... This schema has a table that serves as parent for thousands of child tables (via INHERITS). So effectively, to dump this