On Sun, May 3, 2015 at 8:09 AM, Noah Misch wrote:
> On Fri, May 01, 2015 at 03:23:44PM +0900, Michael Paquier wrote:
>> On Thu, Apr 30, 2015 at 12:17 PM, Noah Misch wrote:
>> > As I pondered this, I felt it would do better to solve a different problem.
>> > The "rm -rf" invocations presumably cre
Thanks for the comments.
2015/05/01 22:35、Robert Haas のメール：
> On Mon, Apr 27, 2015 at 5:07 AM, Shigeru Hanada
> wrote:
>> 2015-04-27 11:00 GMT+09:00 Kouhei Kaigai :
>>> Hanada-san, could you adjust your postgres_fdw patch according to
>>> the above new (previous?) definition.
>>
>> The attached
On Sat, May 02, 2015 at 10:42:24PM +0100, Joe Wildish wrote:
>
> > On 1 May 2015, at 19:51, Robert Haas wrote:
> >
> > On Thu, Apr 30, 2015 at 6:36 PM, Joe Wildish
> > wrote:
> >> I’m wondering if there are other people out there working on implementing
> >> SQL ASSERTION functionality?
> >>
On 04/06/2015 09:36 PM, Emre Hasegeli wrote:
Yes but they were also required by this patch. This version adds more
functions and operators. I can split them appropriately after your
review.
Ok, sounds fine to me.
It is now split.
In which order should I apply the patches?
I also agree w
On Fri, May 01, 2015 at 03:23:44PM +0900, Michael Paquier wrote:
> On Thu, Apr 30, 2015 at 12:17 PM, Noah Misch wrote:
> > As I pondered this, I felt it would do better to solve a different problem.
> > The "rm -rf" invocations presumably crept in to reduce peak disk usage.
> > Considering the rel
> On 1 May 2015, at 19:51, Robert Haas wrote:
>
> On Thu, Apr 30, 2015 at 6:36 PM, Joe Wildish
> wrote:
>> I’m wondering if there are other people out there working on implementing
>> SQL ASSERTION functionality?
>>
>> I’ve recently spent a bit of time looking to implement the execution model
It might be done in the other direction, though - the "writer" thread
might collect current results at the end of the interval.
Yep, you can indeed accumulate per thread and sum on the end of the
interval, but a lock is still needed if you want exact figures.
ISTM that it is what is done fo
On Tue, Apr 21, 2015 at 02:08:00PM -0400, Robert Haas wrote:
> On Tue, Mar 24, 2015 at 3:26 PM, Andres Freund wrote:
[proposal: teach deadlock detector about parallel master waiting on workers]
> > deadlock.c is far from simple, and at least I don't find the control
> > flow to be particularly c
Hi,
On 05/02/15 15:30, Fabien COELHO wrote:
Hello,
The counters are updated when the transaction is finished anyway?
Yes, but the thread does not know it's time to write the results until
it completes the first transaction after the interval ends ...
Let's say the very first query in threa
On 05/01/2015 07:24 PM, Josh Berkus wrote:
O
(A possible compromise position would be to offer a new GUC to
enable/disable the optimization globally; that would add only a reasonably
small amount of control code, and people who were afraid of the change
breaking their apps would probably want a
In doLog, the sample rate test should be mixed in the tlogfile condition
so as to avoid calling rand if there is no logging anyway.
if (tlogfile && sample_rate != 0 && ...)
Oops, wrong logic. Rather:
if (tlogfile && (sample_rate == 0 || ... random stuff))
--
Fabien.
--
Sent via pgsql-
another thing that I find annoying on pgbench is that you can either log
aggregated summary (per interval) or detailed transaction info (possibly
sampled), but not both at the same time.
Here is a review.
Patch applied, compiled and run. Note that it needs a rebase after pgbench
move to src/
Hello,
The counters are updated when the transaction is finished anyway?
Yes, but the thread does not know it's time to write the results until
it completes the first transaction after the interval ends ...
Let's say the very first query in thread #1 takes a minute for some
reason, while the
So, attached is a patch that does 1) and 2) to make clear to the user
how numeric and double precision behave regarding rounding. I am
adding it to CF 2015-06 to keep track of it...
Quick review: patches applies, make check is fine, all is well.
Two minor suggestions:
All the casting tests c
2015-05-02 1:37 GMT+09:00 Andres Freund :
> * ctidscan as an example of custom-scan
> Hasn't really gotten sufficient review.
> => Move
>
I have to agree.
> * Join pushdown support for foreign tables
> Hasn't gotten particularly much review yet. And it doesn't look
> entirely ready to me o
15 matches
Mail list logo
