On Tue, Apr 5, 2016 at 9:47 PM, Robert Haas wrote:
>> I do not pursue something like this without good reason. I'm
>> optimistic that the patch will be accepted if it is carefully
>> considered.
>
> This patch has attracted no reviewers. Any volunteers?
Since nobody has emerged to review this, I
On Tue, Mar 22, 2016 at 4:42 AM, Mithun Cy wrote:
> On Thu, Mar 10, 2016 at 1:36 PM, Amit Kapila wrote:
> >Do you think it makes sense to check the performance by increasing CLOG
> >buffers (patch for same is posted in Speed up Clog thread [1]) >as that also
> >relieves contention on CLOG as pe
On Fri, Apr 8, 2016 at 11:38 AM, Robert Haas wrote:
> Yeah. I've committed the patch now, with some cosmetic cleanup.
>
Thanks Robert !!!
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On 6 April 2016 at 22:17, Andres Freund wrote:
> Quickly skimming 0001 in [4] there appear to be a number of issues:
> * LWLockHeldByMe() is only for debugging, not functional differences
> * ReplicationSlotPersistentData is now in an xlog related header
> * The code and behaviour around name co
On Tue, Apr 5, 2016 at 1:05 PM, Peter Geoghegan wrote:
> On Tue, Apr 5, 2016 at 10:02 AM, Robert Haas wrote:
>> So the first thing here is that the patch seems to be a clear win in
>> this test. For a single copy, it seems to be pretty much a wash.
>> When running 4 copies in parallel, it is abo
On Apr 8, 2016 1:13 AM, "Tom Lane" wrote:
>
> Magnus Hagander writes:
> > On Apr 7, 2016 9:14 PM, "Christian Ullrich"
wrote:
> >> Magnus, do you intend to commit the patch before the feature freeze?
>
> > It's on my list of things to work on this weekend, yeah.
>
> But the stated feature freeze
On Thu, Apr 7, 2016 at 11:43 PM, Fujii Masao wrote:
> On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier
> wrote:
>> On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier
>> wrote:
>>> Here are few things I have noticed:
>>> + for (i = 0; i < max_wal_senders; i++)
>>> + {
>>> + walsnd = &WalSnd
On Wed, Apr 6, 2016 at 10:49 PM, Julien Rouhaud
wrote:
>
> On 06/04/2016 07:38, Amit Kapila wrote:
> > On Tue, Apr 5, 2016 at 11:55 PM, Julien Rouhaud
> >>
> >> In alter_table.sgml, I didn't comment the lock level needed to modify
> >> parallel_degree since it requires an access exclusive lock for
On Tue, Apr 05, 2016 at 03:22:03PM +0900, Etsuro Fujita wrote:
> On 2016/04/04 20:35, Michael Paquier wrote:
> >On Mon, Apr 4, 2016 at 7:49 PM, Etsuro Fujita
> > wrote:
> >>Here is a patch to fix this issue. As proposed by Michael, I modified
> >>execute_dml_stmt so that it uses PQsendQueryParams,
On Fri, Apr 8, 2016 at 12:55 PM, Thomas Munro
wrote:
> On Wed, Apr 6, 2016 at 8:23 PM, Fujii Masao wrote:
>>
>> Okay, I pushed the patch!
>> Many thanks to all involved in the development of this feature!
>
>
> Hi,
>
> I spotted a couple of places in the documentation that still implied there
> w
On Wed, Apr 6, 2016 at 8:23 PM, Fujii Masao wrote:
>
> Okay, I pushed the patch!
> Many thanks to all involved in the development of this feature!
>
Hi,
I spotted a couple of places in the documentation that still implied there
was only one synchronous standby. Please see suggested fixes attach
On Thu, Apr 7, 2016 at 11:10 AM, Robert Haas wrote:
> I prefer units of tuples, with the GUC itself therefore being
> unitless. I suggest we call the parameter replacement_sort_threshold
> and document that (1) the ideal value may depend on the amount of CPU
> cache available to running processes
On 7 April 2016 at 23:32, Robert Haas wrote:
> > Yeah. I understand the reasons for that decision. Per an earlier reply I
> > think we can avoid making them WAL-logged so they can be used on standbys
> > and still achieve usable failover support on physical replicas.
>
> I think at one point we
On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
> Robbie Harwood writes:
>> Tom Lane writes:
>>> Wait a second. So the initial connection-request packet is necessarily
>>> unencrypted under this scheme?
>
>> Yes, by necessity. The username must be sent in the clear, even if only
>> as part of
On Fri, Apr 8, 2016 at 10:23 AM, Peter Eisentraut wrote:
> On 04/07/2016 03:47 AM, Michael Paquier wrote:
>>
>> I have looked at this patch. Do we need to worry as well about
>> SSL_shutdown in disconnection code path? I believe that we don't care
>> much if an error happens at this point but we s
On Thu, Apr 7, 2016 at 6:08 PM, Peter Eisentraut wrote:
> I wish we could avoid the huge, repeated comment blocks. Perhaps we could
> put them at the top of the files once?
I'm fine with that. Do you want to take care of that, or should I?
> Also, why do you write 0UL instead of just 0?
Becaus
On 04/07/2016 03:47 AM, Michael Paquier wrote:
I have looked at this patch. Do we need to worry as well about
SSL_shutdown in disconnection code path? I believe that we don't care
much if an error happens at this point but we surely should consume
any error generated because the SSL context is ke
On Fri, Apr 8, 2016 at 9:29 AM, Andrew Dunstan wrote:
> Not out of the woods yet. Attached is what I got from VS2015 on a fresh W10
> VM, with Michael's patch 0002 and 0004 applied.
Interesting, I have no idea what we are doing differently, and seeing
those errors it seems to me that Petr and I a
On 03/14/2016 09:44 PM, Peter Geoghegan wrote:
On Mon, Mar 14, 2016 at 4:11 PM, Peter Geoghegan wrote:
Yes, with one small difference: I wouldn't be calling ERR_get_error()
in the common case where SSL_get_error() returns SSL_ERROR_NONE, on
the theory that skipping that case represents no risk.
On Thu, Apr 7, 2016 at 4:33 PM, Tom Lane wrote:
> Jeff Janes writes:
>> To summarize the behavior change:
>
>> In the released code, an inserting backend that violates the pending
>> list limit will try to clean the list, even if it is already being
>> cleaned. It won't accomplish anything usefu
On 04/06/2016 04:50 PM, Andrew Dunstan wrote:
On 03/29/2016 09:38 PM, Robert Haas wrote:
On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan
wrote:
I am currently travelling, but my intention is to deal with the
remaining
patches when I'm back home this weekend, unless someone beats me to it.
I wrote:
> Alvaro Herrera writes:
>> FWIW the feature freeze rules state that it is allowed for a committer
>> to request an extension to the feature freeze date for individual
>> patches:
>> https://www.postgresql.org/message-id/CA%2BTgmoY56w5FOzeEo%2Bi48qehL%2BBsVTwy-Q1M0xjUhUCwgGW7-Q%40mail.gma
Jeff Janes writes:
> To summarize the behavior change:
> In the released code, an inserting backend that violates the pending
> list limit will try to clean the list, even if it is already being
> cleaned. It won't accomplish anything useful, but will go through the
> motions until eventually it
Magnus Hagander writes:
> On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote:
>> Magnus, do you intend to commit the patch before the feature freeze?
> It's on my list of things to work on this weekend, yeah.
But the stated feature freeze deadline is tomorrow (Friday), not the
weekend or later.
On Thu, Apr 7, 2016 at 3:56 PM, Kevin Grittner wrote:
>> Unfortunately, this does stop recycling from
>> happening early for B-Tree pages, even though that's probably safe in
>> principle. This is probably not so bad -- it just needs to be
>> considered when reviewing this patch (the same is true
Daniel Verite wrote:
> > * In the "if (cont.cells[idx] != NULL && cont.cells[idx][0] != '\0')"
> > block (line 497 in the attached), can't we do the same thing by using
> > psprintf?
>
> In that block, we can't pass a cell contents as a valist and be done with
> that cell, because duplicates of (
On Mon, Apr 4, 2016 at 9:15 PM, Peter Geoghegan wrote:
> The patch does this:
>
>> --- a/src/backend/access/heap/pruneheap.c
>> +++ b/src/backend/access/heap/pruneheap.c
>> @@ -92,12 +92,21 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
>> * need to use the horizon that includes sl
On Sun, Apr 3, 2016 at 4:09 PM, Jeff Janes wrote:
> On Wed, Mar 30, 2016 at 12:34 PM, Kevin Grittner wrote:
>> On Sat, Mar 19, 2016 at 1:27 AM, Jeff Janes wrote:
>>> I set the value to 1min.
>>>
>>> I set up a test like this:
>>>
>>> pgbench -i
>>>
>>> pgbench -c4 -j4 -T 3600 &
>>>
>>> ### watc
Jeff Janes wrote:
> The proposed change removes that throttle, so that inserters will
> immediately see there is already a cleaner and just go back about
> their business. Due to that, unthrottled backends could add to the
> pending list faster than the cleaner can clean it, leading to
> unbounde
On Thu, Apr 7, 2016 at 11:10 AM, Robert Haas wrote:
> I prefer units of tuples, with the GUC itself therefore being
> unitless. I suggest we call the parameter replacement_sort_threshold
> and document that (1) the ideal value may depend on the amount of CPU
> cache available to running processes
On Wed, Apr 6, 2016 at 9:52 AM, Teodor Sigaev wrote:
> I'm inclining to push v3.1 as one of two winners by size/performance and,
> unlike to pending lock patch, it doesn't change an internal logic of lock
> machinery.
This restricts the memory used by ordinary backends when doing the
cleanup to
On Thu, Apr 7, 2016 at 1:26 PM, Alvaro Herrera
wrote:
> I wonder if the business of appending values of multiple columns
> separated with spaces is doing us any good. Why not require that
> there's a single column in the cell? If the user wants to put things
> together, they can use format() or
Alvaro Herrera wrote:
> Daniel Verite wrote:
> > > * A few examples in docs. The psql manpage should have at least two new
> > > examples showing the crosstab features, one with the simplest case you
> > > can think of, and another one showing all the features.
> >
> > Added that in the EXAMPLES
On 04/07/2016 09:50 PM, Stephen Frost wrote:
Robert, José,
I've rebased this on top of master and added a few additional checks and
regression tests.
Applies and compiles cleanly, of course. Passes all 164 tests, too.
- make installcheck-world ok
- interdiff checked, nothing very surprising
*
I wonder if the business of appending values of multiple columns
separated with spaces is doing us any good. Why not require that
there's a single column in the cell? If the user wants to put things
together, they can use format() or just || the fields together. What
benefit is there to the ' '?
On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote:
>
> * Magnus Hagander wrote:
>
>> On Tue, Mar 29, 2016 at 5:09 PM, David Steele
wrote:
>
>
>>> It seems like this patch should be set "ready for committer". Can one
of
>>> the reviewers do that if appropriate?
>
>
>> I'll pick it up to do that a
Robert, José,
I've rebased this on top of master and added a few additional checks and
regression tests.
I'm planning to continue going over the patch tomorrow morning with
plans to push this before the feature freeze deadline.
Thanks!
Stephen
From a0724d91ffd1a93034d5b5d5df2b4ff54339d763 Mon S
All, Andres,
Now that we have begun removing the if (!superuser) checks and instead
relying on the GRANT system to determine who is allowed to call certain
functions, it's time to consider functions beyond the initial set.
In particular, the pg_logical_* functions have superuser checks and
those
Daniel Verite wrote:
> > regression=# select * from pg_class \crosstabview relnatts
> > \crosstabview: missing second argument
> > regression-#
>
> Fixed. This was modelled after the behavior of:
> select 1 \badcommand
> but I've changed to mimic what happens with:
> select 1 \g /some/invali
Alvaro Herrera writes:
> Tom Lane wrote:
>> I don't know if you have time to look at this now --- my clock says it's
>> already Friday morning in New Zealand.
> FWIW the feature freeze rules state that it is allowed for a committer
> to request an extension to the feature freeze date for individu
* Magnus Hagander wrote:
On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote:
It seems like this patch should be set "ready for committer". Can one of
the reviewers do that if appropriate?
I'll pick it up to do that as well as committing it.
Magnus, do you intend to commit the patch be
* Petr Jelinek wrote:
On 07/04/16 00:50, Michael Paquier wrote:
On Thu, Apr 7, 2016 at 7:44 AM, Michael Paquier
wrote:
On Thu, Apr 7, 2016 at 6:11 AM, Petr Jelinek
wrote:
On 06/04/16 22:50, Andrew Dunstan wrote:
* VS2015 appears to create version 12 solution files, not
version 14
Tom Lane wrote:
> Anyway, while refactoring the make_join_rel/add_paths_to_joinrel division
> of labor wouldn't be such a big deal in itself, I don't want to commit a
> change to JoinType only to undo it later; that would be too much churn.
> So I think we need to resolve this question before we c
David Rowley writes:
> [ unique_joins_2016-04-07.patch ]
Just had a thought about this, which should have crystallized a long
time ago perhaps. Where I'd originally imagined you were going with
this idea is to do what the thread title actually says, and check for
joins in which the *outer* side
On 07/04/16 17:32, Robert Haas wrote:
Second, I'm not sure whether it was a good design decision to make
logical slots a special kind of object that sit off to the side,
neither configuration (like postgresql.conf) nor WAL-protected data
(like pg_clog and the data files themselves), but it was ce
On Thu, Apr 7, 2016 at 11:05 AM, Robert Haas wrote:
> I spent some time today reading through the new 0001 and in general I
> think it looks pretty good.
Cool.
> 1. Changing cost_sort to consider disk access as 90% sequential, 10%
> random rather than 75% sequential, 25% random. As far as I can
On Thu, Apr 7, 2016 at 1:17 PM, Peter Geoghegan wrote:
>> I certainly agree that GUCs that aren't easy to tune are bad. I'm
>> wondering whether the fact that this one is hard to tune is something
>> that can be fixed. The comments about "padding" - a term I don't
>> like, because it to me impli
On Mon, Mar 21, 2016 at 2:01 AM, Peter Geoghegan wrote:
> On Thu, Mar 17, 2016 at 1:13 PM, Robert Haas wrote:
>> OK, I have now committed 0001
>
> I attach a revision of the external quicksort patch and supplementary
> small patches, rebased on top of the master branch.
I spent some time today r
Peter Eisentraut writes:
> On 04/04/2016 09:20 PM, Michael Paquier wrote:
>> Likely an oversight not tracked by the buildfarm. What are you using here?
> It should be a rather unspectactular Debian system. I have tried a
> bunch of different compilers and optimization options, without success.
On 07/04/16 12:26, Andres Freund wrote:
Hi,
On 2016-04-06 20:03:20 +0200, Petr Jelinek wrote:
Attached patch adds filtering of both database and origin. Added tests with
slightly less hardcoding than what you proposed above.
Not a fan of creating & dropping another database - that's really ra
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> It'd be possible to fix (1) by adding "drop if exists", but I think the
> whole thing is wrongheaded due to (2). Perhaps the needs of the test
> could be met by granting/revoking some rights explicitly to current_user
> (ie, the test superuser)? That
Stephen Frost writes:
> In pg_dump, include pg_catalog and extension ACLs, if changed
This patch added a regression test step that creates some roles
and doesn't drop them again. This is unacceptable, because
(1) it breaks the ability to do "make installcheck" more than once.
(2) it leaves rol
On Thu, Apr 7, 2016 at 6:55 AM, Robert Haas wrote:
>> In reality there will be multiple processes running at the same time (e.g
>> backends when running parallel query), significantly reducing the amount of
>> cache per process, making the replacement sort inefficient and thus
>> eliminating the r
"postgres_sure" writes:
> I found "Do not include the table's name in the specification of a target
> column
> â for example, UPDATE tab SET tab.col = 1 is invalid." in
> the documentation.
> Some people usually like to update table by alias. They want to add this
> feature.
On 7 April 2016 at 16:45, Tom Lane wrote:
> Don't know which version of the SQL spec you're looking at,
It was the draft 95 version, cos (being text file) it's easiest to
read :). I'll learn my lesson next time and expand the 2008 one.
> but SQL:2008 has
>
> ::=
> UPDATE [ [ AS ] ]
>
On 04/07/2016 01:22 AM, Michael Paquier wrote:
On Wed, Mar 23, 2016 at 1:47 AM, David Steele wrote:
On 3/16/16 12:19 PM, David Steele wrote:
Hi Peter,
On 3/9/16 3:08 PM, Michael Paquier wrote:
Here are some comments about 0002
<...>
I think that we had better do something like the attache
Magnus Hagander wrote:
> On Wed, Mar 30, 2016 at 7:47 PM, Alvaro Herrera
> wrote:
>
> > José Luis Tallón wrote:
> >
> > > Just wanted to suggest two minor mods to the review e-mails
> > > auto-generated by the app:
> > >
> > > * Prepend a [review] tag to the e-mail subject
> > > ... so th
On Thu, Apr 7, 2016 at 8:49 AM, Thomas Munro
wrote:
> Here is a version that includes an attempt to describe the
> situation in the documentation.
Pushed with minor adjustments to the docs. Mostly I thought your
new text was more appropriate as just another paragraph than as a
"note". The prev
06.04.2016 23:52, Peter Geoghegan:
On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote:
Personally, I like documenting assertions, and will sometimes write
assertions that the compiler could easily optimize away. Maybe going
*that* far is more a matter of personal style, but I think an
assert
On 04/04/2016 09:20 PM, Michael Paquier wrote:
Likely an oversight not tracked by the buildfarm. What are you using here?
It should be a rather unspectactular Debian system. I have tried a
bunch of different compilers and optimization options, without success.
I'll keep looking.
--
Sent
Fabien COELHO wrote:
> While testing it I had a funny pattern, something like:
>
> pgbench --random-seed=123 -M prepared -T 3 -P 1 -S
> 1.0: 600 tps
> 2.0: 600 tps
> 3.0: 600 tps
The output should include the random seed used, whether it was passed
with --random-seed, environment variabl
Geoff Winkless writes:
> I grabbed the wrong section of the doc; I should of course have pasted
> the searched version:
> ::=
> UPDATE
> SET
> [ WHERE ]
> My point is still the same though :)
Don't know which version of the SQL spec you're looki
On Mon, Apr 4, 2016 at 8:38 PM, Peter Geoghegan wrote:
> On Sun, Apr 3, 2016 at 2:09 PM, Jeff Janes wrote:
>> Also, HOT-cleanup should stop the bloat increase once the snapshot
>> crosses the old_snapshot_threshold without even needing to wait until
>> the next autovac runs.
>>
>> Does the code i
Alvaro Herrera wrote:
Thanks for looking into that patch!
> regression=# select * from pg_class \crosstabview relnatts
> \crosstabview: missing second argument
> regression-#
Fixed. This was modelled after the behavior of:
select 1 \badcommand
but I've changed to mimic what happens w
On Thu, Apr 7, 2016 at 6:48 PM, Andres Freund wrote:
>
> On 2016-04-07 18:40:14 +0530, Amit Kapila wrote:
> > This is the data with -b tpcb-like@1 with 20-min run for each version
and I
> > could see almost similar results as the data posted in previous e-mail.
> >
> > Client Count/Patch_ver (tps)
On Tue, Apr 5, 2016 at 10:34 PM, Craig Ringer wrote:
>> Right, but right now you probably *aren't* do doing any kind of
>> logical decoding from a master server to a standby, because there's
>> squat in the core distribution that could make use of that capability.
>> So you never get as far as dis
On 7 April 2016 at 15:51, I wrote:
> ::=
> UPDATE
> SET
> WHERE CURRENT OF
I grabbed the wrong section of the doc; I should of course have pasted
the searched version:
::=
UPDATE
SET
[ WHERE ]
M
On 7 April 2016 at 14:48, Merlin Moncure wrote:
>
> On Thu, Apr 7, 2016 at 4:39 AM, postgres_sure wrote:
> > Hi,
> >
> > I found "Do not include the table's name in the specification of a target
> > column
> > — for example, UPDATE tab SET tab.col = 1 is invalid." in
> > the docu
David Rowley writes:
> I've attached an updated patch which introduces JOIN_INNER_UNIQUE and
> JOIN_LEFT_UNIQUE. So unique inner joins no longer borrow JOIN_SEMI.
OK.
> In EXPLAIN, I named these new join types "Unique Inner" and "Unique
> Left".
Hm. I'm back to being unhappy about the amount o
On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier
wrote:
> On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier
> wrote:
>> Here are few things I have noticed:
>> + for (i = 0; i < max_wal_senders; i++)
>> + {
>> + walsnd = &WalSndCtl->walsnds[i];
>> No volatile pointer to prevent code reorder
It means that you can't separate between OS caused, and pgbench order
caused performance differences.
I'm not objecting to adding an option for this; but I think Fabien is
right that it shouldn't be the default.
Yep.
Andres, attached is a simple POC with an option & environment variable
(w
Sorry for not responding to this thread again sooner. I was on
vacation Thursday-Sunday, and have been playing catch-up since then.
On Sun, Apr 3, 2016 at 8:24 AM, Tomas Vondra
wrote:
> Secondly, master is faster only if there's enough on-CPU cache for the
> replacement sort (for the memtuples h
On 2016-04-07 09:46:27 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote:
> >> So I have no mathematical doubt that changing the seed is the right default
> >> setting, thus I think that the current behavior is fine. However I'm okay
> >> if
> >>
On Wed, Apr 6, 2016 at 5:15 PM, Jim Nasby wrote:
> On 4/6/16 11:06 AM, Robert Haas wrote:
>> This is too late for 9.6 at this point and certainly requires
>> discussion anyway, so please add it to the next CommitFest.
>
> If the goal here is to free up space via truncation when there's a real
> em
On Thu, Apr 7, 2016 at 4:41 PM, Andres Freund wrote:
> On 2016-03-31 20:21:02 +0300, Alexander Korotkov wrote:
> > ! BEGIN_BUFSTATE_CAS_LOOP(bufHdr);
> >
> > ! Assert(BUF_STATE_GET_REFCOUNT(state) > 0);
> > ! wasDirty = (state & BM_DIRTY) ? true : false;
> > ! state |= BM_DIRTY |
On Thu, Apr 7, 2016 at 10:42 PM, Kevin Grittner wrote:
> On Thu, Apr 7, 2016 at 3:26 AM, Simon Riggs wrote:
>
>> We agree its a bug, so the deadline doesn't need to constrain us.
>
> I'm not sure there is consensus across the community on that.
>
>> I suggest we should apply what we have then fix
On Thu, Apr 7, 2016 at 4:39 AM, postgres_sure wrote:
> Hi,
>
> I found "Do not include the table's name in the specification of a target
> column
> — for example, UPDATE tab SET tab.col = 1 is invalid." in
> the documentation.
>
> Some people usually like to update table by alias.
Andres Freund writes:
> On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote:
>> So I have no mathematical doubt that changing the seed is the right default
>> setting, thus I think that the current behavior is fine. However I'm okay if
>> someone wants to control the randomness for some reason (mayb
On 2016-03-31 20:21:02 +0300, Alexander Korotkov wrote:
> ! BEGIN_BUFSTATE_CAS_LOOP(bufHdr);
>
> ! Assert(BUF_STATE_GET_REFCOUNT(state) > 0);
> ! wasDirty = (state & BM_DIRTY) ? true : false;
> ! state |= BM_DIRTY | BM_JUST_DIRTIED;
> ! if (state == oldstate)
> !
On Thu, Apr 7, 2016 at 9:15 AM, Andres Freund wrote:
> It's not about "covering it up"; it's about actually being able to take
> action based on benchmark results, and about practically being able to
> run benchmarks. The argument above means essentially that we need to run
> a significant number
On 2016-04-07 18:40:14 +0530, Amit Kapila wrote:
> On Thu, Apr 7, 2016 at 10:16 AM, Andres Freund wrote:
> >
> > Hi,
> >
> > On 2016-04-07 09:14:00 +0530, Amit Kapila wrote:
> > > On Sat, Apr 2, 2016 at 5:25 PM, Amit Kapila
> wrote:
> > > I have ran exactly same test on intel x86 m/c and the resu
On 2016-04-07 08:58:16 -0400, Robert Haas wrote:
> On Thu, Apr 7, 2016 at 5:56 AM, Fabien COELHO wrote:
> > I think that it depends on what you want, which may vary:
> >
> > (1) "exactly" reproducible runs, but one run may hit a particular
> > steady state not representative of what happens
On Thu, Apr 7, 2016 at 10:16 AM, Andres Freund wrote:
>
> Hi,
>
> On 2016-04-07 09:14:00 +0530, Amit Kapila wrote:
> > On Sat, Apr 2, 2016 at 5:25 PM, Amit Kapila
wrote:
> > I have ran exactly same test on intel x86 m/c and the results are as
below:
>
> Thanks for running these tests!
>
> > Clien
On Thu, Apr 7, 2016 at 5:56 AM, Fabien COELHO wrote:
> I think that it depends on what you want, which may vary:
>
> (1) "exactly" reproducible runs, but one run may hit a particular
> steady state not representative of what happens in general.
>
> (2) runs which really vary from one to the
On 7 April 2016 at 12:23, Simon Riggs wrote:
> For 0002
>
For find_best_foreign_key_quals() how can this ever match 2 FKs with
different keys?
The fkrel references the foreignrel, which has a single PK. How can the FK
have a different number of columns to the PK?
Assuming that is possible/makes
Hi,
On 04/07/2016 01:23 PM, Simon Riggs wrote:
On 7 April 2016 at 00:15, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
Right. Fixed.
0001 committed. I added comments and a fastpath when no triggers are
present.
For 0002, I would be more comfortable adding
enable_fk_plans
On Thu, Apr 7, 2016 at 7:29 PM, Amit Kapila wrote:
> On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote
> wrote:
>>
>> On 2016/04/07 15:26, Fujii Masao wrote:
>> > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila
>> > wrote:
>> >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao
>> >> wrote:
>> >>> Yes if the
On 7 April 2016 at 00:15, Tomas Vondra wrote:
> Right. Fixed.
0001 committed. I added comments and a fastpath when no triggers are
present.
For 0002, I would be more comfortable adding
enable_fk_plans = on (true) | off
even if we decided to remove that parameter that before release.
--
Hello Andres,
If you run the test for longer... Or explicitly iterate over IVs. At the
very least we need to make pgbench output the IV used, to have some
chance of repeating tests.
Note that I'm not against providing a way to repeat tests "exactly", and I
have suggested two means: environme
On Thu, Apr 7, 2016 at 3:26 AM, Simon Riggs wrote:
> We agree its a bug, so the deadline doesn't need to constrain us.
I'm not sure there is consensus across the community on that.
> I suggest we should apply what we have then fix the rest later
> when we work out how.
On that, I agree. I wil
On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote:
>
> >> (2) runs which really vary from one to the next, so as
> >> to have an idea about how much it may vary, what is the
> >> performance stability.
> >
> >I don't think this POV makes all that much sense. If you do something
> >non-comp
On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote
wrote:
>
> On 2016/04/07 15:26, Fujii Masao wrote:
> > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila
wrote:
> >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao
wrote:
> >>> Yes if the variable that we'd like to pass to a backend is BOOL, INT,
> >>> REAL,
(2) runs which really vary from one to the next, so as
to have an idea about how much it may vary, what is the
performance stability.
I don't think this POV makes all that much sense. If you do something
non-comparable, then the results aren't, uh, comparable. Which also
means there
Hi,
On 2016-04-06 20:03:20 +0200, Petr Jelinek wrote:
> Attached patch adds filtering of both database and origin. Added tests with
> slightly less hardcoding than what you proposed above.
Not a fan of creating & dropping another database - that's really rather
expensive. And we're in a target th
On 2016-04-07 11:56:12 +0200, Fabien COELHO wrote:
> (2) runs which really vary from one to the next, so as
> to have an idea about how much it may vary, what is the
> performance stability.
I don't think this POV makes all that much sense. If you do something
non-comparable, then the r
Hello Andres,
et al I was wondering why it's a good idea for pgbench to do
INSTR_TIME_SET_CURRENT(start_time);
srandom((unsigned int) INSTR_TIME_GET_MICROSEC(start_time));
to initialize randomness and then
for (i = 0; i < nthreads; i++)
thread->random_sta
Hi,
On 2016-04-06 21:58:50 -0400, Robert Haas wrote:
> I spent a lot of time testing things on power2 today
Thanks for that!
> It's fairly mysterious to me why there is so much jitter in the
> results on this machine. By doing prewarming in a consistent fashion,
> we make sure that every disk ru
Hi,
pondering
http://archives.postgresql.org/message-id/CA%2BTgmoZJdA6K7-17K4A48rVB0UPR98HVuaNcfNNLrGsdb1uChg%40mail.gmail.com
et al I was wondering why it's a good idea for pgbench to do
INSTR_TIME_SET_CURRENT(start_time);
srandom((unsigned int) INSTR_TIME_GET_MICROSEC(start_time)
Hi,
I found "Do not include the table's name in the specification of a target column
— for example, UPDATE tab SET tab.col = 1 is invalid." in the
documentation.
Some people usually like to update table by alias. They want to add this
feature.
So I get the source in the gram.y
On Thu, Apr 7, 2016 at 2:15 AM, Jim Nasby wrote:
> On 4/6/16 11:06 AM, Robert Haas wrote:
>
>> This is too late for 9.6 at this point and certainly requires
>> discussion anyway, so please add it to the next CommitFest.
>>
>
> If the goal here is to free up space via truncation when there's a rea
1 - 100 of 105 matches
Mail list logo
