>> 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 base
On Thu, Jul 18, 2013 at 10:02 AM, David Fetter 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 must b
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,
> > >
Hitoshi Harada 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 access to rd_ind
On Thu, Jul 18, 2013 at 9:40 AM, Satoshi Nagayasu wrote:
> (2013/07/18 2:31), Fujii Masao wrote:
>
>> On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu
>> wrote:
>>
>>> (2013/07/04 3:58), Fujii Masao wrote:
>>>
For the test, I just implemented the regclass-version of pg_relpages()
(pat
> 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 th
On Wed, Jul 17, 2013 at 7:11 AM, Tom Lane wrote:
> Kevin Grittner 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 index relation is fresh.
Something
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
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.
* Bu
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 = INSTR_TIME_
(2013/07/18 2:31), Fujii Masao wrote:
On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu 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.
SELECT pg
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
>
> 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 transact
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
reason a
>> 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 f
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
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):
>http
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 propagati
On 07/17/2013 04:30 PM, Dimitri Fontaine wrote:
> Josh Berkus 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
Josh Berkus 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 readline-completion-bug-free
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 t
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 o
On Wed, Jul 17, 2013 at 4:57 PM, Tom Lane 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 variable, and there
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 aga
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.
>
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
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 p
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
Robert Haas writes:
> On Sun, Jul 14, 2013 at 8:41 PM, Tom Lane 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 does not bother to initialize
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) D
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 17.07.2013 02:18, Michael Paquier wrote:
On Tue, Jul 16, 2013 at 2:24 AM, Fujii Masao wrote:
On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
wrote:
Ok, I've committed this patch now. Finally, phew!
I found that this patch causes the assertion failure. When I set up simple
replication
On Wed, Jul 17, 2013 at 2:20 PM, Andrew Dunstan 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 post
On Fri, Jul 12, 2013 at 9:15 AM, Amit kapila 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 of regression tests,
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 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 aut
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.
> > +#
Markus Wanner 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 step of this di
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:
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.
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
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
On Wed, Jul 17, 2013 at 1:25 PM, Robert Haas wrote:
> On Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh 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 suc
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 noti
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
On Tue, Jul 16, 2013 at 3:00 PM, Satoshi Nagayasu wrote:
> (2013/07/04 3:58), Fujii Masao wrote:
>> On Wed, Jun 26, 2013 at 12:39 AM, Robert Haas wrote:
>>> On Thu, Jun 20, 2013 at 2:32 PM, Fujii Masao wrote:
Since pg_relpages(oid) doesn't exist, pg_relpages() is in the same
situation
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 Mon, Jul 15, 2013 at 12:45 AM, Gurjeet Singh 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 palloc can ever
Alvaro Herrera 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 hand, trying to be ni
Tom Lane escribió:
> Alvaro Herrera 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 the others when
>
On 07/17/2013 05:21 AM, Gurjeet Singh wrote:
> On Tue, Jul 16, 2013 at 4:04 PM, Pavel Stehule wrote:
>
>> 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 se
Kevin Grittner 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 (pgsql-hackers@postgresql.org)
To make changes to y
>>> 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
On Wed, Jul 17, 2013 at 2:54 PM, Amit Kapila 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:
> http://www.google.com/patents/US7194589?dq=645987&hl=en&sa=X&ei=kn7mUZ-PIsWq
> rAe99oDgBw&s
On Wed, Jul 17, 2013 at 1:54 PM, Greg Smith 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 didn't say tha
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() t
On Wed, Jul 17, 2013 at 8:21 AM, Gurjeet Singh 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 Tue, Jul 16, 2013 at 4:04 PM, Pavel Stehule wrote:
> 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 interesting
because v6 does le
On Wed, Jul 17, 2013 at 5:20 PM, Dave Page wrote:
> On Wed, Jul 17, 2013 at 2:55 AM, Michael Paquier
> 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
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 Tuesday, July 16, 2013 10:16 PM Ants Aasma wrote:
> On Jul 14, 2013 9:46 PM, "Greg Smith" 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 reproduce
> back t
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 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
>>> 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 noti
>> 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
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
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 OS
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
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 woul
> 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 ti
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*
transa
On Wed, Jul 17, 2013 at 2:55 AM, Michael Paquier
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
> build I created is
On Fri, Jul 12, 2013 at 3:57 PM, Stas Kelvich wrote:
> 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
> bit of the cube h
74 matches
Mail list logo
