On Thu, Apr 16, 2015 at 8:57 PM, Heikki Linnakangas wrote:
> Oh, hang on, that's not necessarily true. On promotion, the standby
archives
> the last, partial WAL segment from the old timeline. That's just wrong
> (http://www.postgresql.org/message-id/52fcd37c.3070...@vmware.com), and in
> fact I so
On 2015-04-20 17:13:29 -0400, Bruce Momjian wrote:
> Didn't you think any of the TODO threads had workable solutions? And
> don't expect adding an additional file per relation will be zero cost
> --- added over the lifetime of 200M transactions, I question if this
> approach would be a win.
Note
On 2015/04/21 10:07, Kyotaro HORIGUCHI wrote:
At Mon, 20 Apr 2015 16:40:52 +0900, Etsuro Fujita wrote
in <5534ad84.3020...@lab.ntt.co.jp>
However, I'd
like to propose to rename "Foreign Update" ("Foreign Delete") of
ModifyTable simply to "Update" ("Delete") not only because (1) that
solves the
On Fri, Feb 13, 2015 at 4:57 PM, Michael Paquier wrote:
> Moved patch to CF 2015-02 to not lose track of it, also because it does not
> seem it received a proper review.
This patch does not apply anymore, so attached is a rebased version.
The comments mentioned here have not been addressed:
http:/
Hi all,
As mentioned in $subject, the TAP tests of pg_rewind are currently not
run by buildfarm machines as the buildfarm client uses installcheck to
run the tests in src/bin. A patch is attached to correct the problem.
Regards,
--
Michael
diff --git a/src/bin/pg_rewind/Makefile b/src/bin/pg_rewi
Kaigai-san,
I reviewed the Custom/Foreign join API patch again after writing a patch of
join push-down support for postgres_fdw.
2015/03/26 10:51、Kouhei Kaigai のメール：
>>> Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just
>> building (or searching from a list) a RelOptI
Hi,
At Mon, 20 Apr 2015 16:40:52 +0900, Etsuro Fujita
wrote in <5534ad84.3020...@lab.ntt.co.jp>
> On 2015/04/17 13:16, Amit Langote wrote:
> > On 17-04-2015 PM 12:35, Etsuro Fujita wrote:
> >> (2) that might cause the problem of associating subplans' update
> >> information with subplans' scan i
On 04/20/2015 02:13 PM, Bruce Momjian wrote:
> Didn't you think any of the TODO threads had workable solutions? And
> don't expect adding an additional file per relation will be zero cost
> --- added over the lifetime of 200M transactions, I question if this
> approach would be a win.
Well, the o
On 2015-04-21 AM 03:29, Robert Haas wrote:
> On Wed, Apr 8, 2015 at 3:38 AM, Amit Langote wrote:
>> On 08-04-2015 PM 12:46, Amit Kapila wrote:
>>> Going forward, I think we can improve the same if we decide not to shutdown
>>> parallel workers till postmaster shutdown once they are started and
>>>
On Sun, Apr 19, 2015 at 9:37 PM, Peter Geoghegan wrote:
> Attached patch, V3.4, implements what I believe you and Heikki have in
> mind here.
Any plans to look at this, Svenne? You are signed up as a reviewer on
the commitfest app. A review of the documentation, and interactions
with other featur
On 4/20/15 4:13 PM, Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 03:58:19PM -0500, Jim Nasby wrote:
I also think there's better ways we could handle *all* our cleanup
work. Tuples have a definite lifespan, and there's potentially a lot
of efficiency to be gained if we could track tuples through
On Thu, Mar 19, 2015 at 11:13 AM, Robert Haas wrote:
> Here is yet another version of this patch. In addition to the fixes
> mentioned above, this version includes some minor rebasing around
> recent commits, and also better handling of the case where we discover
> that we cannot launch workers a
Bruce Momjian wrote:
> On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > This seems simple to implement: keep two counters, where the second one
> > is pages we skipped cleanup in. Once that counter hits SOME_MAX_VALUE,
> > reset the first counter so
On 4/20/15 2:45 AM, Sawada Masahiko wrote:
Current patch adds new source file src/backend/access/heap/frozenmap.c
which is quite similar to visibilitymap.c. They have similar code but
are separated for now. I do refactoring these source code like adding
bitmap.c, if needed.
My feeling is we'd d
On Mon, Apr 20, 2015 at 09:56:20PM +0100, Simon Riggs wrote:
> On 20 April 2015 at 20:28, Jeff Janes wrote:
>
>
> But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job,
> while the user waits, which is fundamentally VACUUM's duty to do in the
> background?
>
>
> A
On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I think the limit has to be in terms of a percentage of the table size.
> > For example, if we do one SELECT on a table with all non-dirty pages, it
> > would be good to know that 5% of the pages were pru
On Mon, Apr 20, 2015 at 05:04:14PM -0400, Robert Haas wrote:
> On Mon, Apr 20, 2015 at 4:11 PM, Bruce Momjian wrote:
> > Slightly improved patch applied.
>
> Is it?
The patch has a slightly modified 'if' statement to check a constant
before calling a function, and use elseif:
< + if
On Tue, Apr 14, 2015 at 7:02 PM, Robert Haas wrote:
> On Tue, Apr 14, 2015 at 6:22 PM, Peter Geoghegan wrote:
>> Why is that good?
>
> We did discuss this before. I've recapped some of what I believe to
> be the most salient points below.
>
>> I think that people were all too quick to dismiss th
On Mon, Apr 20, 2015 at 3:28 PM, Jeff Janes wrote:
> But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job, while
> the user waits, which is fundamentally VACUUM's duty to do in the
> background? If there are a handful of very hot pages, then it makes sense
> not to wait for vacuu
On Mon, Apr 20, 2015 at 03:58:19PM -0500, Jim Nasby wrote:
> >>I also think there's better ways we could handle *all* our cleanup
> >>work. Tuples have a definite lifespan, and there's potentially a lot
> >>of efficiency to be gained if we could track tuples through their
> >>stages of life... but
On Mon, Apr 20, 2015 at 4:11 PM, Bruce Momjian wrote:
> Slightly improved patch applied.
Is it?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On 4/20/15 2:09 PM, Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 01:59:17PM -0500, Jim Nasby wrote:
On 4/20/15 1:48 PM, Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 04:45:34PM +0900, Sawada Masahiko wrote:
Attached WIP patch adds Frozen Map which enables us to avoid whole
table vacuuming even
On 20 April 2015 at 20:28, Jeff Janes wrote:
> But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job,
> while the user waits, which is fundamentally VACUUM's duty to do in the
> background?
>
Agreed. I don't see a % as giving us anything at all.
The idea is that we want to turn
On Thu, Apr 9, 2015 at 05:33:20PM -0400, Bruce Momjian wrote:
> On Thu, Apr 9, 2015 at 12:32:23PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > Should this be listed in the release notes as a backward-incompatibility?
> >
> > Isn't this a backpatchable bug fix?
>
> Uh, I don'
On Mon, Apr 20, 2015 at 12:28:11PM -0700, Jeff Janes wrote:
> But why should 1 SELECT or 20 SELECTs or 200 SELECTs have to do a job, while
> the user waits, which is fundamentally VACUUM's duty to do in the background?
> If there are a handful of very hot pages, then it makes sense not to wait for
On Sun, Apr 19, 2015 at 7:09 PM, Jeff Janes wrote:
> I did literally the simplest thing I could think of as a proof of concept
> patch, to see if it would actually fix things. I just jumped back a certain
> number of blocks occasionally and prefetched them forward, then resumed the
> regular b
On 4/19/15 7:46 AM, Palle Girgensohn wrote:
> Just poking this old thread again. What happened here, is anyone putting work
> into this area at the moment?
I plan to look at it for 9.6.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, Apr 20, 2015 at 04:19:22PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > I think the limit has to be in terms of a percentage of the table size.
> > For example, if we do one SELECT on a table with all non-dirty pages, it
> > would be good to know that 5% of the pages were pru
On Mon, Apr 20, 2015 at 10:33 AM, Bruce Momjian wrote:
> On Thu, Apr 16, 2015 at 03:41:54PM +0100, Simon Riggs wrote:
> > That is how we arrive at the idea of a cleanup limit, further enhanced
> by a
> > limit that applies only to dirtying clean blocks, which we have 4?
> recent votes
> > in favo
Bruce Momjian wrote:
> I think the limit has to be in terms of a percentage of the table size.
> For example, if we do one SELECT on a table with all non-dirty pages, it
> would be good to know that 5% of the pages were pruned --- that tells me
> that another 19 SELECTs will totally prune the tab
On Mon, Apr 20, 2015 at 01:59:17PM -0500, Jim Nasby wrote:
> On 4/20/15 1:48 PM, Bruce Momjian wrote:
> >On Mon, Apr 20, 2015 at 04:45:34PM +0900, Sawada Masahiko wrote:
> >>Attached WIP patch adds Frozen Map which enables us to avoid whole
> >>table vacuuming even when full scan is required: preve
On Sun, Apr 19, 2015 at 3:02 PM, Jim Nasby wrote:
> Is there a fundamental reason SQL/plpgsql functions won't accept record as
> an input type? If not, can someone point me at a patch that might show how
> much work would be involved in adding support?
>
> My particular use case is a generic func
On 4/20/15 1:48 PM, Bruce Momjian wrote:
On Mon, Apr 20, 2015 at 04:45:34PM +0900, Sawada Masahiko wrote:
Attached WIP patch adds Frozen Map which enables us to avoid whole
table vacuuming even when full scan is required: preventing XID
wraparound failures.
Frozen Map is a bitmap with one bit p
On 4/20/15 11:11 AM, Robert Haas wrote:
On Wed, Apr 15, 2015 at 5:06 PM, Greg Stark wrote:
This is my point though (you're right that "flushed" isn't always the
same as eviction but that's not the important point here). Right now
we only demote when we consider buffers for eviction. But we prom
On Mon, Apr 20, 2015 at 04:45:34PM +0900, Sawada Masahiko wrote:
> Attached WIP patch adds Frozen Map which enables us to avoid whole
> table vacuuming even when full scan is required: preventing XID
> wraparound failures.
>
> Frozen Map is a bitmap with one bit per heap page, and quite similar
>
On Wed, Apr 8, 2015 at 3:38 AM, Amit Langote
wrote:
> On 08-04-2015 PM 12:46, Amit Kapila wrote:
>> Going forward, I think we can improve the same if we decide not to shutdown
>> parallel workers till postmaster shutdown once they are started and
>> then just allocate them during executor-start ph
On Wed, Apr 8, 2015 at 3:34 AM, David Rowley wrote:
> On 8 April 2015 at 14:24, Robert Haas wrote:
>> I think one of the philosophical questions that has to be answered
>> here is "what does it mean to talk about the cost of a parallel
>> plan?". For a non-parallel plan, the cost of the plan mea
On 20 April 2015 at 18:33, Bruce Momjian wrote:
> Also, I am also not sure we should be designing features at this stage
> in our release process.
>
I see this more as a process of gaining approval. I don't think patches at
the back of the queue should get the "its too late treatment" just beca
On Thu, Apr 16, 2015 at 03:41:54PM +0100, Simon Riggs wrote:
> That is how we arrive at the idea of a cleanup limit, further enhanced by a
> limit that applies only to dirtying clean blocks, which we have 4? recent
> votes
> in favour of.
>
> I would personally be in favour of a parameter to cont
On 4/20/15 1:50 AM, Jeff Janes wrote:
Shouldn't completely empty pages be set as all-visible in the VM? If
so, can't we just find the largest not-all-visible page and move
forward from there, instead of moving backwards like we currently do?
If the entire table is all-visible, we wo
On Tue, Apr 7, 2015 at 11:58 PM, Amit Kapila wrote:
> One disadvantage of retaining parallel-paths could be that it can
> increase the number of combinations planner might need to evaluate
> during planning (in particular during join path evaluation) unless we
> do some special handling to avoid e
On Thu, Apr 9, 2015 at 5:33 PM, Bruce Momjian wrote:
> On Thu, Apr 9, 2015 at 12:32:23PM -0300, Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>>
>> > Should this be listed in the release notes as a backward-incompatibility?
>>
>> Isn't this a backpatchable bug fix?
>
> Uh, I don't think so. I th
On Sat, Apr 11, 2015 at 12:03 PM, Artem Luzyanin wrote:
> Thank you again for your feedback. I have improved the patch with your
> suggestions. Please let me know what you think and if I can do anything
> else.
>
> Current CommitFest link for this patch is:
> https://commitfest.postgresql.org/5/20
Heikki Linnakangas wrote:
> * The transformations of the arrays in get_state() and set_state() functions
> are a bit complicated. The seqam_get_state() function returns two C arrays,
> and pg_sequence_get_state() turns them into a text[] array. Why not
> construct the text[] array directly in the
On Mon, Apr 20, 2015 at 11:00 AM, Merlin Moncure wrote:
>> Hmm, interesting point. It's possible that we'd still have problems
>> with everything maxing out at 32 on some workloads, but at least it'd
>> be a little harder to max out at 32 than at 5.
>
> Do we have any reproducible test cases to e
On Wed, Apr 15, 2015 at 5:06 PM, Greg Stark wrote:
> This is my point though (you're right that "flushed" isn't always the
> same as eviction but that's not the important point here). Right now
> we only demote when we consider buffers for eviction. But we promote
> when we pin buffers. Those two
On Mon, Apr 20, 2015 at 9:56 AM, Robert Haas wrote:
> On Wed, Apr 15, 2015 at 5:00 PM, Martijn van Oosterhout
> wrote:
>> I've been following this thread from the side with interest and got
>> twigged by the point about loss of information. If you'd like better
>> information about relative ages
On Wed, Apr 15, 2015 at 5:00 PM, Martijn van Oosterhout
wrote:
> I've been following this thread from the side with interest and got
> twigged by the point about loss of information. If you'd like better
> information about relative ages, you can acheive this by raising the
> cap on the usage cou
Michael Paquier wrote:
> And currawong is satisfied with this patch and the new buildfarm code,
> test modules being run as testmodules-install-check-C:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=currawong&dt=2015-04-18%2014%3A51%3A14
> So this closes the loop for this thread.
Yay!
On 4/20/15 4:40 AM, Sawada Masahiko wrote:
>
> Thank you for updating the patch.
>
> One question about regarding since v7 (or later) patch is;
> What is the different between OBJECT logging and SESSION logging?
In brief, session logging can log anything that happens in a user
session while obje
On 04/20/15 05:07, Andres Freund wrote:
Hi,
On 2015-04-19 22:51:53 +0200, Tomas Vondra wrote:
The reason why I'm asking about this is the multivariate statistics patch -
while optimizing the planning overhead, I realized that considerable amount
of time is spent decompressing the statistics (
On Sun, Apr 19, 2015 at 10:01 PM, Michael Paquier
wrote:
> Note as well that this patch uses the following patches fixing
> independent issues:
> ...
Attached is v4. I added a switch in config.pl to be consistent with
./configure and --enable-tap-tests.
--
Michael
From f532bbd2522b3a1784038d9863
On 20/04/15 12:05, Andres Freund wrote:
On 2015-04-20 12:49:39 +0300, Heikki Linnakangas wrote:
With the patch, pg_class.relam column references to the pg_seqam table for
sequences, but pg_indexam for indexes. I believe it's the first instance
where we reuse a "foreign key" column like that. It'
On 2015-04-20 12:49:39 +0300, Heikki Linnakangas wrote:
> With the patch, pg_class.relam column references to the pg_seqam table for
> sequences, but pg_indexam for indexes. I believe it's the first instance
> where we reuse a "foreign key" column like that. It's not a real foreign
> key, of course
On 03/15/2015 09:07 PM, Petr Jelinek wrote:
Slightly updated version of the patch.
Mainly rebased against current master (there were several conflicts) and
fixed some typos, no real functional change.
I also attached initial version of the API sgml doc.
Thanks!
With the patch, pg_class.relam
On Thu, Apr 16, 2015 at 2:34 AM, David Steele wrote:
> On 4/15/15 11:30 AM, Sawada Masahiko wrote:
>> On Wed, Apr 15, 2015 at 10:52 AM, Sawada Masahiko
>> wrote:
>>> I tested v8 patch with CURSOR case I mentioned before, and got
>>> segmentation fault again.
>>> Here are log messages in my envir
Oh, and I build it on top of f92fc4c95ddcc25978354a8248d3df22269201bc
On 20-04-2015 10:36, Svenne Krap wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, failed
> Implements feature: tested, passed
> Spec compliant:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
Hi,
I have (finally) found time to review this.
The syntax is
On 2015-04-20 11:26:29 +0300, Heikki Linnakangas wrote:
> I just realized that it talks about "replication identifier" as the new
> fundamental concept. The system table is called "pg_replication_identifier".
> But that's like talking about "index identifiers", instead of just indexes,
> and callin
On 04/17/2015 11:54 AM, Andres Freund wrote:
I've attached a rebased patch, that adds decision about origin logging
to the relevant XLogInsert() callsites for "external" 2 byte identifiers
and removes the pad-reusing version in the interest of moving forward.
Putting aside the 2 vs. 4 byte iden
On 2015/04/16 16:05, Etsuro Fujita wrote:
> On 2015/03/23 2:57, Tom Lane wrote:
>> Etsuro Fujita writes:
>>> [ fdw-inh-8.patch ]
>>
>> I've committed this with some substantial rearrangements, notably:
>
>> * As I mentioned earlier, I got rid of a few unnecessary restrictions on
>> foreign tables
On 2015-04-20 11:09:20 +0300, Heikki Linnakangas wrote:
> Can you name some of the bigger problems you'd have?
Several parts of the system are O(#max_replication_slots). Having 100k
outgoing logical replication slots is going to be expensive.
Nothing unsolvable, but the 65k 16 bit limit surely is
On 2015-04-20 01:04:18 -0700, Jeff Janes wrote:
> Was this reproducible?
Yes, at least with an old version of the patch.
I don't think you could see a difference using exactly that with the
newer versions which have the 5 page limit. After all it'll pretty much
never reach it.
> > That's not a u
On 04/17/2015 11:45 PM, Petr Jelinek wrote:
>The argument to move to 4 bytes is a poor one. If it was reasonable in
>terms of code or cosmetic value then all values used in the backend
>would be 4 bytes. We wouldn't have any 2 byte values anywhere. But we
>don't do that.
>
>The change does nothin
On 04/17/2015 11:36 PM, Simon Riggs wrote:
On 17 April 2015 at 19:18, Heikki Linnakangas wrote:
To be honest, I'm not entirely sure what we're arguing over.
When arguing over something you consider small, it is customary to allow
the author precedence. We can't do things our own way all the t
On Mon, Sep 29, 2014 at 2:13 AM, Andres Freund wrote:
>
> 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
rewritte
On Tue, Apr 7, 2015 at 11:22 AM, Sawada Masahiko wrote:
> On Tue, Apr 7, 2015 at 7:53 AM, Jim Nasby wrote:
>> On 4/6/15 5:18 PM, Greg Stark wrote:
>>>
>>> Only I would suggest thinking of it in terms of two orthogonal boolean
>>> flags rather than three states. It's easier to reason about whether
On 2015/04/17 13:16, Amit Langote wrote:
> On 17-04-2015 PM 12:35, Etsuro Fujita wrote:
>> (2) that might cause the problem of associating subplans' update
>> information with subplans' scan information, pointed out by Tom [1].
> Having realized how it really works now, my +1 to "Foreign Modifying
68 matches
Mail list logo
