To clarify what state this is all in: Fabien's latest
pgbench-throttle-v15.patch is the ready for a committer version. The
last two revisions are just tweaking the comments at this point, and
his version is more correct than my last one.
Got it. I will take care of this.
Please find
To clarify what state this is all in: Fabien's latest
pgbench-throttle-v15.patch is the ready for a committer version. The
last two revisions are just tweaking the comments at this point, and
his version is more correct than my last one.
Got it. I will take care of this.
Please find
On Wed, July 17, 2013 05:27, Tom Lane wrote:
Michael Paquier michael.paqu...@gmail.com writes:
It happens that I work occasionally on multiple builds based on
FWIW, I've been doing this for while:
where $project is mostly the patchname, $commit_hash is extracted like this:
commit_hash=$( cd
On Fri, Jul 12, 2013 at 3:57 PM, Stas Kelvich stas.kelv...@gmail.comwrote:
Hello.
here is a patch adding to cube extension support for compressed
representation of point cubes. If cube is a point, i.e. has coincident
lower left and upper right corners, than only one corner is stored. First
On Wed, Jul 17, 2013 at 2:55 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Hi all,
It happens that I work occasionally on multiple builds based on
different stable branches at the same time to check fixes that need to
be backpatched, and I tend to easily lose track on which version the
Hello Tatsuo,
Now I have question regarding the function.
./pgbench -p 5433 -S -T 10 -R 1 test
tps = 7133.745911 (including connections establishing)
What does average rate limit lag mean? From the manual:
[...]
So in my understanding the number shows the delay time before *each*
Hello Tatsuo,
Now I have question regarding the function.
./pgbench -p 5433 -S -T 10 -R 1 test
tps = 7133.745911 (including connections establishing)
What does average rate limit lag mean? From the manual:
[...]
So in my understanding the number shows the delay time before *each*
I've looked this version.
The only reservation I have is that when changing the owner of a schema,
the new owner is not always checked. I would suggest to query the new
owner to check that it matches (5, 11, 12), just as you do in 3.
Also, reowning is tested several times (5, 11, 12). I
On 7/17/13 2:31 AM, Tatsuo Ishii wrote:
./pgbench -p 5433 -S -T 10 -R 1 test
average rate limit lag: 862.534 ms (max 2960.913 ms)
tps = 7133.745911 (including connections establishing)
tps = 7135.130810 (excluding connections establishing)
What does average rate limit lag mean?
The whole
Thanks for detailed explainations. I now understand the function.
Good. I've looked into the documentation. I'm not sure how I could improve
it significantly without adding a lot of text which would also add a lot
of confusion to the casual reader.
I'm going to test your patches on Mac
The whole concept of lag with the rate limit is complicated.
I must agree on that point, their interpretation is subtle.
At one point I thought this should be a debugging detail, rather than
exposing the user to it. The problem is that if you do that, you might
not notice that your limit
The whole concept of lag with the rate limit is complicated.
I must agree on that point, their interpretation is subtle.
At one point I thought this should be a debugging detail, rather than
exposing the user to it. The problem is that if you do that, you might
not notice that your limit
The whole concept of lag with the rate limit is complicated.
I must agree on that point, their interpretation is subtle.
At one point I thought this should be a debugging detail, rather than
exposing the user to it. The problem is that if you do that, you might
not notice that your limit
On Monday, July 08, 2013 2:47 PM Heikki Linnakangas wrote:
Ok, I've committed this patch now. Finally, phew!
Few doubts while reading the code:
1. Why in function WALInsertSlotAcquireOne(int slotno), it does
START_CRIT_SECTION() to
Lock out cancel/die interrupts, whereas other places call
On 7/16/13 11:36 PM, Ants Aasma wrote:
As you know running a full suite of write benchmarks takes a very long
time, with results often being inconclusive (noise is greater than
effect we are trying to measure).
I didn't say that. What I said is that over a full suite of write
benchmarks, the
On Tuesday, July 16, 2013 10:16 PM Ants Aasma wrote:
On Jul 14, 2013 9:46 PM, Greg Smith g...@2ndquadrant.com wrote:
I updated and re-reviewed that in 2011:
http://www.postgresql.org/message-id/4d31ae64.3000...@2ndquadrant.com
and commented on why I think the improvement was difficult to
tps = 9818.741060 (including connections establishing)
So I thought I could squeeze 1 TPS from my box.
Then I tried with -R 5000 tps.
number of transactions actually processed: 1510640
average rate limit lag: 0.304 ms (max 19.101 ms)
tps = 5035.409397 (including connections establishing)
On Wed, Jul 17, 2013 at 5:20 PM, Dave Page dp...@pgadmin.org wrote:
On Wed, Jul 17, 2013 at 2:55 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Hi all,
It happens that I work occasionally on multiple builds based on
different stable branches at the same time to check fixes that need to
On Tue, Jul 16, 2013 at 4:04 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
I did a some performance tests of v5 and v6 version and there v5 is
little bit faster than v6, and v6 has significantly higher stddev
Thanks Pavel.
The difference in average seems negligible, but stddev is
On Wed, Jul 17, 2013 at 8:21 AM, Gurjeet Singh gurj...@singh.im wrote:
What's the procedure of moving a patch to the next commitfest?
Never mind, I see an email from Josh B. regarding this on my corporate
account.
Best regards,
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterpriseDB Inc.
On 2013-07-17 15:46:00 +0530, Amit Kapila wrote:
On Monday, July 08, 2013 2:47 PM Heikki Linnakangas wrote:
Ok, I've committed this patch now. Finally, phew!
Few doubts while reading the code:
1. Why in function WALInsertSlotAcquireOne(int slotno), it does
START_CRIT_SECTION() to
On Wed, Jul 17, 2013 at 1:54 PM, Greg Smith g...@2ndquadrant.com wrote:
On 7/16/13 11:36 PM, Ants Aasma wrote:
As you know running a full suite of write benchmarks takes a very long
time, with results often being inconclusive (noise is greater than
effect we are trying to measure).
I
On Wed, Jul 17, 2013 at 2:54 PM, Amit Kapila amit.kap...@huawei.com wrote:
I think Oracle also use similar concept for making writes efficient, and
they have patent also for this technology which you can find at below link:
tps = 9818.741060 (including connections establishing)
So I thought I could squeeze 1 TPS from my box.
Then I tried with -R 5000 tps.
number of transactions actually processed: 1510640
average rate limit lag: 0.304 ms (max 19.101 ms)
tps = 5035.409397 (including connections
Kevin Grittner kgri...@postgresql.org writes:
Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.
The buildfarm members that use -DCLOBBER_CACHE_ALWAYS say this patch
is broken.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On 07/17/2013 05:21 AM, Gurjeet Singh wrote:
On Tue, Jul 16, 2013 at 4:04 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
I did a some performance tests of v5 and v6 version and there v5 is
little bit faster than v6, and v6 has significantly higher stddev
Thanks Pavel.
The difference
Tom Lane escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Well, Tom opined in
http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that
the current patch is okay. I have a mild opinion that it should instead
print only SHR_LOCK when both bits are set, and one of
Alvaro Herrera alvhe...@2ndquadrant.com writes:
The one I was talking about is the second case, which prints
KEYSHR_LOCK|EXCL_LOCK to mean that there's a FOR SHARE lock. I have no
problem reading it this way, but I fear that someone unfamiliar with
these bits might be confused. On the other
On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh gurj...@singh.im wrote:
Agreed that there's overhead in allocating list items, but is it more
overhead than pushing functions on the call stack? Not sure, so I leave it
to others who understand such things better than I do.
If you think that a
Hello Tatsuo,
The lag is reasonnable, althought no too good. One transaction is
about 1.2 ms, the lag is much smaller than that, and you are at about
50% of the maximum load. I've got similar figures on my box for such
settings. It improves if your reduce the number of clients.
No, 5000 TPS
On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu sn...@uptime.jp wrote:
(2013/07/04 3:58), Fujii Masao wrote:
On Wed, Jun 26, 2013 at 12:39 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 20, 2013 at 2:32 PM, Fujii Masao masao.fu...@gmail.com wrote:
Since pg_relpages(oid) doesn't
On 14.07.2013 20:12, Stephen Frost wrote:
* Heikki Linnakangas (heikki.linnakan...@iki.fi) wrote:
This patch alleviates that in two ways. First, instead of storing pointers
in the hash table, store 16-bit indexes into the hist_entries array. That
slashes the size of the hash table to 1/2 or 1/4
Tom Lane escribió:
My feeling about this code is that the reason we print the infomask in
hex is so you can see exactly which bits are set if you care, and that
the rest of the line ought to be designed to interpret the bits in as
reader-friendly a way as possible. So I don't buy the notion
On Wed, Jul 17, 2013 at 1:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh gurj...@singh.im wrote:
Agreed that there's overhead in allocating list items, but is it more
overhead than pushing functions on the call stack? Not sure, so I leave
it
On 07/16/2013 07:16 PM, Andreas Karlsson wrote:
I guess one problem is to implement writing to the WAL with the smallest
possible performance hit. As far as I can see there are two possible
approaches: either write to WAL when NOTIFY is run or write to WAL on
commit. The former seems more in
Peter Eisentraut wrote:
In general, I find these new wordings to be a loss of clarity. There is
no indication on the SELECT man page or in the documentation index what
a row-level lock is at all.
I would suggest that these changes be undone, except that the old
SELECT FOR ... be replaced
On 07/17/2013 02:08 PM, Josh Berkus wrote:
There shouldn't be any major problems with implementing LISTEN on the
slaves since LISTEN is done in memory.
Actually, that's not the hard part. Listeners need to be registered on
the standby, which requires a write to a system catalog, currently.
Hackers,
We've seen this before:
http://www.postgresql.org/message-id/b42b73150906271019k6212ba71u6263bc43a8ec8...@mail.gmail.com
I've run across this again, and am posting it here just in case someone
should be struck by some amazing inspiration on where the problem might
be. Here's the issue:
Markus Wanner mar...@bluegap.ch writes:
But okay, you're saying we *have* and *want* a guarantee that even a
superuser cannot execute arbitrary native code via libpq (at least in
default installs w/o extensions).
There are several problems confused into that sentence already. I think
the next
Amit kapila escribió:
+# This includes the default configuration directory included to support
+# ALTER SYSTEM statement.
+#
+# WARNING: User should not remove below include_dir or directory config,
+# as both are required to make ALTER SYSTEM command work.
+# Any
On 07/17/2013 12:01 PM, Alvaro Herrera wrote:
Both of these seem like they would make troubleshooters' lives more
difficult. I think we should just parse the auto file automatically
after parsing postgresql.conf, without requiring the include directive
to be there.
Wait, I thought the auto
On 07/17/2013 02:50 PM, Josh Berkus wrote:
Hackers,
We've seen this before:
http://www.postgresql.org/message-id/b42b73150906271019k6212ba71u6263bc43a8ec8...@mail.gmail.com
I've run across this again, and am posting it here just in case someone
should be struck by some amazing inspiration on
On Fri, Jul 12, 2013 at 9:15 AM, Amit kapila amit.kap...@huawei.com wrote:
The sleep is used to ensure the effects of pg_reload_conf() can be visible.
That strikes me as almost certain to result in random regression test
failures. My experience, as a man who helps to maintain a very large
suite
On Wed, Jul 17, 2013 at 2:20 PM, Andrew Dunstan and...@dunslane.net wrote:
On 07/17/2013 02:50 PM, Josh Berkus wrote:
Hackers,
We've seen this before:
http://www.postgresql.org/message-id/b42b73150906271019k6212ba71u6263bc43a8ec8...@mail.gmail.com
I've run across this again, and am
On 17.07.2013 02:18, Michael Paquier wrote:
On Tue, Jul 16, 2013 at 2:24 AM, Fujii Masaomasao.fu...@gmail.com wrote:
On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ok, I've committed this patch now. Finally, phew!
I found that this patch causes the
On 17.07.2013 15:24, Andres Freund wrote:
On 2013-07-17 15:46:00 +0530, Amit Kapila wrote:
Few doubts while reading the code:
1. Why in function WALInsertSlotAcquireOne(int slotno), it does
START_CRIT_SECTION() to
Lock out cancel/die interrupts, whereas other places call
HOLD_INTERRUPTS()
On 07/17/2013 08:52 PM, Dimitri Fontaine wrote:
the next step of this discussion should be about talking about the
problems we have and figuring out *if* we want to solve them, now that
we managed to explicitely say what we want as a project.
- per-installation (not even per-cluster) DSO
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 14, 2013 at 8:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
However, fixing that doesn't yield much joy; initdb stalls and then
crashes with
PANIC: stuck spinlock (40054a88) detected at xlog.c:2182
The reason for that is that the code
Robert Haas escribió:
This feature doesn't strike me as a good candidate for regression
testing anyway. Keep in mind that people are intended to be able to
run make installcheck against a deployed system without messing it up.
This is my opinion as well.
--
Álvaro Herrera
I wrote:
I'm inclined to agree that #error is the only realistic answer in
general, though we could probably go ahead with equating
pg_memory_barrier to pg_compiler_barrier on specific architectures we
know are single-processor-only. Unfortunately, that means we just
raised the bar for
On 07/17/2013 12:20 PM, Andrew Dunstan wrote:
What happens when you do this with psql -n ? My suspicion is it's the
tab completion code, which I occasionally find it useful to disable this
way - sadly one can't do that on the fly AFAIK.
Well, that works. But it disables readline, not just tab
On 2013-07-17 17:05:40 -0400, Alvaro Herrera wrote:
Robert Haas escribió:
This feature doesn't strike me as a good candidate for regression
testing anyway. Keep in mind that people are intended to be able to
run make installcheck against a deployed system without messing it up.
This
On 07/17/2013 03:17 PM, Andres Freund wrote:
On 2013-07-17 17:05:40 -0400, Alvaro Herrera wrote:
Robert Haas escribió:
This feature doesn't strike me as a good candidate for regression
testing anyway. Keep in mind that people are intended to be able to
run make installcheck against a
On Wed, Jul 17, 2013 at 4:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This would not be hard to fix, I think.
Really? Given that the memory barrier primitives are supposed to be,
well, primitive, I don't think this is exactly a trivial problem.
There's no good place to initialize such a
Josh Berkus wrote:
So, an even more practical workaround (I've been using cat | psql), but
still a mysterious issue.
How often do your files contain tabs? I have seen cases where tab
completion messes things up by asking you after a tab whether you really
want to complete due to the number of
On 07/17/2013 03:37 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
So, an even more practical workaround (I've been using cat | psql), but
still a mysterious issue.
How often do your files contain tabs? I have seen cases where tab
completion messes things up by asking you after a tab
Josh Berkus j...@agliodbs.com writes:
So, an even more practical workaround (I've been using cat | psql), but
still a mysterious issue.
As a workaround you might try \e with EDITOR=emacs or some of the other
solutions you've been pasting, maybe even cat, so that you can switch
that
On 07/17/2013 04:30 PM, Dimitri Fontaine wrote:
Josh Berkus j...@agliodbs.com writes:
So, an even more practical workaround (I've been using cat | psql), but
still a mysterious issue.
As a workaround you might try \e with EDITOR=emacs or some of the other
solutions you've been pasting,
If we are going to add ALTER SYSTEM, then I'd like to consider recasting
ALTER ROLE ALL SET in terms of ALTER SYSTEM as well, because the ALTER
ROLE ALL syntax was a hack. At least it should be possible to consider
various levels of system. Who knows, maybe a future version will
allow
On Tue, 2013-07-16 at 04:23 +, Amit kapila wrote:
Why do we need to expose this setting to a user?
a) This can be a knob to turn this feature off. This has been asked by
few people,
one of the mail link is mentioned below (refer towards end of mail
in the link):
Fabien,
Hello Tatsuo,
The lag is reasonnable, althought no too good. One transaction is
about 1.2 ms, the lag is much smaller than that, and you are at about
50% of the maximum load. I've got similar figures on my box for such
settings. It improves if your reduce the number of clients.
Hello Tatsuo,
For me, the error message is not quite right, because progress == 0
case is considered error as well in your patch. I sugges you change
the error message something like:
thread progress delay (-P) must be positive number (%s)\n,
Please find attached a new
On 7/17/13 9:16 PM, Tatsuo Ishii wrote:
Now suppose we have 3 transactions and each has following values:
d(0) = 10
d(1) = 20
d(2) = 30
t(0) = 100
t(1) = 110
t(2) = 120
That says pgbench expects the duration 10 for each
transaction. Actually, the first transaction runs slowly for some
reason
The spec defines two types of aggregate function classed as ordered set
function, as follows:
1. An inverse distribution function taking one argument (which must be
a grouped column or otherwise constant within groups) plus a sorted
group with exactly one column:
=# SELECT (func(p)
On 7/17/13 9:16 PM, Tatsuo Ishii wrote:
Now suppose we have 3 transactions and each has following values:
d(0) = 10
d(1) = 20
d(2) = 30
t(0) = 100
t(1) = 110
t(2) = 120
That says pgbench expects the duration 10 for each
transaction. Actually, the first transaction runs slowly for some
On Thursday, July 18, 2013 2:36 AM Alvaro Herrera wrote:
Robert Haas escribió:
This feature doesn't strike me as a good candidate for regression
testing anyway. Keep in mind that people are intended to be able to
run make installcheck against a deployed system without messing it
up.
(2013/07/18 2:31), Fujii Masao wrote:
On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu sn...@uptime.jp wrote:
(2013/07/04 3:58), Fujii Masao wrote:
For the test, I just implemented the regclass-version of pg_relpages()
(patch attached) and tested some cases. But I could not get that problem.
On 7/17/13 11:34 PM, Tatsuo Ishii wrote:
My example is for 1 client case. So concurrent clients are not the
issue here.
Sorry about that, with your clarification I see what you were trying to
explain now. The code initializes the target time like this:
thread-throttle_trigger =
It's always annoyed me that pgindent insists on adjusting vertical
whitespace around #else and related commands. This has, for example,
rendered src/include/storage/barrier.h nigh illegible: you get things
like
/*
* lwsync orders loads with respect to each other, and similarly with stores.
*
On Thu, Jul 18, 2013 at 03:15:14AM +, Andrew Gierth wrote:
The spec defines two types of aggregate function classed as ordered set
function, as follows:
1. An inverse distribution function taking one argument (which must be
a grouped column or otherwise constant within groups) plus a
On Wed, Jul 17, 2013 at 7:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@postgresql.org writes:
Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.
The buildfarm members that use -DCLOBBER_CACHE_ALWAYS say this patch
is broken.
Looks like rd_indpred is not correct if
Sorry about that, with your clarification I see what you were trying
to explain now. The code initializes the target time like this:
thread-throttle_trigger = INSTR_TIME_GET_MICROSEC(start);
And then each time a transaction fires, it advances the reference time
forward based on the
On Thu, Jul 18, 2013 at 9:40 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
(2013/07/18 2:31), Fujii Masao wrote:
On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu sn...@uptime.jp
wrote:
(2013/07/04 3:58), Fujii Masao wrote:
For the test, I just implemented the regclass-version of
Hitoshi Harada umi.tan...@gmail.com writes:
Looks like rd_indpred is not correct if index relation is fresh.
Something like this works for me.
- if (indexRel-rd_indpred != NIL)
+ if (RelationGetIndexPredicate(indexRel) != NIL)
Hm, yeah, the direct
On Thursday, July 18, 2013 12:31 AM Alvaro Herrera wrote:
Amit kapila escribió:
+# This includes the default configuration directory included to
support
+# ALTER SYSTEM statement.
+#
+# WARNING: User should not remove below include_dir or directory
config,
+# as both
On Thu, Jul 18, 2013 at 10:02 AM, David Fetter da...@fetter.org wrote:
On Thu, Jul 18, 2013 at 03:15:14AM +, Andrew Gierth wrote:
The spec defines two types of aggregate function classed as ordered set
function, as follows:
1. An inverse distribution function taking one argument (which
Sorry about that, with your clarification I see what you were trying
to explain now. The code initializes the target time like this:
thread-throttle_trigger = INSTR_TIME_GET_MICROSEC(start);
And then each time a transaction fires, it advances the reference time
forward based on the
77 matches
Mail list logo
