On Tue, Aug 4, 2015 at 2:18 AM, Jeff Janes wrote:
> On Mon, Jul 27, 2015 at 1:40 PM, Simon Riggs wrote:
>>
>> On 22 July 2015 at 17:11, Jeff Janes wrote:
>>>
>>> On Wed, Jul 22, 2015 at 6:59 AM, Robert Haas
>>> wrote:
On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes
wrote:
> Att
> I think that the degree of parallelism to consider is nclients, not
> nthreads: while connection time is accumulated in conn_time, other
> clients are possibly doing their transactions, in parallel,
I'm not sure about this. I think pgbench will not start transactions
until all clients establish
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/
>
I'v
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 discussion has happen
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 your
> 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 lat
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 should add that the way
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 where
>> alignment is not required
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
>> on it if someone can giv
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 fr
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 any rows that
are visibl
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 t
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
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
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
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 rece
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 l_orderkey
=?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 for thousands of child
> tables (v
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 the join.
>>
> >
>
>> My reaso
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 schema,
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)
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)
22 matches
Mail list logo