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 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
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 that
On Mon, Apr 20, 2015 at 4:11 PM, Bruce Momjian br...@momjian.us 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
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 I don't see
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 pruned ---
On Mon, Apr 20, 2015 at 3:28 PM, Jeff Janes jeff.ja...@gmail.com 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
On Tue, Apr 14, 2015 at 7:02 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 14, 2015 at 6:22 PM, Peter Geoghegan p...@heroku.com 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
On Sun, Apr 19, 2015 at 9:37 PM, Peter Geoghegan p...@heroku.com 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
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 Mon, Apr 20, 2015 at 09:56:20PM +0100, Simon Riggs wrote:
On 20 April 2015 at 20:28, Jeff Janes jeff.ja...@gmail.com 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
On 20 April 2015 at 20:28, Jeff Janes jeff.ja...@gmail.com 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
On Mon, Apr 20, 2015 at 05:04:14PM -0400, Robert Haas wrote:
On Mon, Apr 20, 2015 at 4:11 PM, Bruce Momjian br...@momjian.us 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:
On Thu, Mar 19, 2015 at 11:13 AM, Robert Haas robertmh...@gmail.com 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
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 only
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
then just
Hi,
At Mon, 20 Apr 2015 16:40:52 +0900, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
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
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 kai...@ak.jp.nec.com のメール：
Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just
building (or searching from a
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
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:
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't think so.
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 object
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 Tue, Apr 7, 2015 at 11:22 AM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Tue, Apr 7, 2015 at 7:53 AM, Jim Nasby jim.na...@bluetreble.com 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.
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 calling the
On Thu, Apr 16, 2015 at 2:34 AM, David Steele da...@pgmasters.net wrote:
On 4/15/15 11:30 AM, Sawada Masahiko wrote:
On Wed, Apr 15, 2015 at 10:52 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
I tested v8 patch with CURSOR case I mentioned before, and got
segmentation fault again.
Here
On Sun, Apr 19, 2015 at 10:01 PM, Michael Paquier
michael.paqu...@gmail.com 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
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 nothing
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
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 Scan
On Mon, Sep 29, 2014 at 2:13 AM, Andres Freund and...@anarazel.de wrote:
On 2014-09-28 19:51:36 +0100, Simon Riggs wrote:
On 27 September 2014 09:29, Andres Freund and...@anarazel.de wrote:
On 2014-09-27 10:23:33 +0300, Heikki Linnakangas wrote:
This patch has gotten a fair amount of
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,
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:
On 04/17/2015 11:36 PM, Simon Riggs wrote:
On 17 April 2015 at 19:18, Heikki Linnakangas hlinn...@iki.fi 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
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
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
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
On 2015/04/16 16:05, Etsuro Fujita wrote:
On 2015/03/23 2:57, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
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 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's
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=currawongdt=2015-04-18%2014%3A51%3A14
So this closes the loop for this thread.
Yay!
On Mon, Apr 20, 2015 at 9:56 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 15, 2015 at 5:00 PM, Martijn van Oosterhout
klep...@svana.org 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
On Wed, Apr 15, 2015 at 5:00 PM, Martijn van Oosterhout
klep...@svana.org 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
On 20 April 2015 at 18:33, Bruce Momjian br...@momjian.us 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
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 control
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
On Tue, Apr 7, 2015 at 11:58 PM, Amit Kapila amit.kapil...@gmail.com 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
On Thu, Apr 9, 2015 at 5:33 PM, Bruce Momjian br...@momjian.us 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
On Sat, Apr 11, 2015 at 12:03 PM, Artem Luzyanin lisyono...@yahoo.ca 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:
On Wed, Apr 15, 2015 at 5:06 PM, Greg Stark st...@mit.edu 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.
On Mon, Apr 20, 2015 at 11:00 AM, Merlin Moncure mmonc...@gmail.com 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
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 AM?
On Wed, Apr 8, 2015 at 3:34 AM, David Rowley dgrowle...@gmail.com wrote:
On 8 April 2015 at 14:24, Robert Haas robertmh...@gmail.com 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
On Wed, Apr 8, 2015 at 3:38 AM, Amit Langote
langote_amit...@lab.ntt.co.jp 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
On 4/20/15 11:11 AM, Robert Haas wrote:
On Wed, Apr 15, 2015 at 5:06 PM, Greg Stark st...@mit.edu 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.
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
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
to
On Sun, Apr 19, 2015 at 3:02 PM, Jim Nasby jim.na...@bluetreble.com 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
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: preventing
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 table,
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 pruned ---
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 Sun, Apr 19, 2015 at 7:09 PM, Jeff Janes jeff.ja...@gmail.com 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
On Mon, Apr 20, 2015 at 10:33 AM, Bruce Momjian br...@momjian.us 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
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 04/19/2015 11:51 PM, Tomas Vondra wrote:
Hi there,
in the past we've repeatedly discussed the option of using a different
compression algorithm (e.g. lz4), but every time the discussion died off
because of fear of possible patent issues [1] [2] and many other
threads. Have we decided it's
On Sun, Apr 19, 2015 at 10:38 PM, Jim Nasby jim.na...@bluetreble.com
wrote:
On 4/19/15 9: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
67 matches
Mail list logo
