On 2015-09-02 14:36:51 -0400, Robert Haas wrote:
> On Wed, Sep 2, 2015 at 2:20 PM, Fabien COELHO wrote:
> >> I'm wondering if percentages instead of weights would be a better
> >> idea. That'd mean you'd be forced to be more careful when adding another
> >> script (having to adjust the percentages
On Wed, Sep 2, 2015 at 4:31 PM, Josh Berkus wrote:
> On 09/02/2015 02:25 PM, Tomas Vondra wrote:
>>
>> As I explained, spindles have very little to do with it - you need
>> multiple I/O requests per device, to get the benefit. Sure, the DBAs
>> should know how many spindles they have and should be
On Wed, Sep 2, 2015 at 2:31 PM, Josh Berkus wrote:
> On 09/02/2015 02:25 PM, Tomas Vondra wrote:
> >
> > As I explained, spindles have very little to do with it - you need
> > multiple I/O requests per device, to get the benefit. Sure, the DBAs
> > should know how many spindles they have and shou
On 2015-09-02 12:24:33 -0700, Peter Geoghegan wrote:
> "Read fetch". One argument past to the intrinsic here specifies that
> the variable will be read only. I did things this way because I
> imagined that there would be very limited uses for the macro only. I
> probably cover almost all interestin
On 2015-09-02 22:46:59 +0100, Greg Stark wrote:
> On Sun, Jul 26, 2015 at 1:46 PM, Andres Freund wrote:
> > To me it sounds like this shouldn't go through the full ReadBuffer()
> > rigamarole. That code is already complex enough, and here it's really
> > not needed. I think it'll be much easier to
On 2015-09-02 14:31:35 -0700, Josh Berkus wrote:
> On 09/02/2015 02:25 PM, Tomas Vondra wrote:
> >
> > As I explained, spindles have very little to do with it - you need
> > multiple I/O requests per device, to get the benefit. Sure, the DBAs
> > should know how many spindles they have and should
On 2015-09-02 19:49:13 +0100, Greg Stark wrote:
> I can take the blame for this formula.
>
> It's called the "Coupon Collector Problem". If you hit get a random
> coupon from a set of n possible coupons, how many random coupons would
> you have to collect before you expect to have at least one of
On Wed, Sep 2, 2015 at 02:41:46PM -0400, Robert Haas wrote:
> 4. Therefore, I think that we should instead use logical replication,
> which might be either synchronous or asynchronous. When you modify
> one copy of the data, that change will then be replicated to all other
> nodes. If you are OK
On Wed, Sep 2, 2015 at 3:13 PM, Andres Freund wrote:
> I'd be less brief in this case then, no need to be super short here.
Okay.
>> It started out that way, but Tom felt that it was better to have a
>> USE_MEM_PREFETCH because of the branch below...
>
> That doesn't mean we shouldn't still prov
On 2015-09-02 16:02:00 -0700, Peter Geoghegan wrote:
> On Wed, Sep 2, 2015 at 3:13 PM, Andres Freund wrote:
> > That's just a question of how to formulate this though?
> >
> > pg_rfetch(((char *) state->memtuples ) + 3 * sizeof(SortTuple) +
> > offsetof(SortTuple, tuple))?
> >
> > For something h
On Wed, Sep 2, 2015 at 12:03:36PM -0700, Josh Berkus wrote:
> Well, there is a WIP patch for that, which IMHO would be much improved
> by having a concrete use-case like this one. What nobody is working on
> -- and we've vetoed in the past -- is a way of automatically failing and
> removing from
On Wed, Sep 2, 2015 at 04:50:32PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Fri, Aug 28, 2015 at 10:34:38PM -0700, AI Rumman wrote:
>
> > > In pg_upgrade, how about adding a feature to copy data directory over
> > > network.
> > > That is, we can run pg_upgrade from our new host
Hello KaiGai-san,
I've discovered a bug in the proposed patch - when resetting the hash
table after the first batch, it does this:
memset(hashtable->buckets, 0, sizeof(nbuckets * sizeof(HashJoinTuple)));
The first 'sizeof' is bogus, so this only zeroes the first 8 bytes of
the array (usually
On 2015-09-02 17:03:46 -0400, Robert Haas wrote:
> On Wed, Sep 2, 2015 at 4:50 PM, Andrew Dunstan wrote:
> > Tell me what's needed and I'll look at creating a buildfarm test module for
> > it.
>
> You run the tests via: make -C src/test/ssl check
>
> But nota bene security caveats:
>
> commit e
On Wed, Sep 2, 2015 at 4:12 PM, Andres Freund wrote:
>> Well, still needs to work for tuplestore, which does not have a SortTuple.
>
> Isn't it even more trivial there? It's just an array of void*'s? So
> prefetch(state->memtuples + 3 + readptr->current)?
All I meant is that there couldn't be one
On 2015-09-02 16:23:13 -0700, Peter Geoghegan wrote:
> On Wed, Sep 2, 2015 at 4:12 PM, Andres Freund wrote:
> >> Well, still needs to work for tuplestore, which does not have a SortTuple.
> >
> > Isn't it even more trivial there? It's just an array of void*'s? So
> > prefetch(state->memtuples + 3
On Wed, Sep 2, 2015 at 11:32 PM, Fujii Masao wrote:
> Did you confirm that replication user can complete pg_rewind
> after this patch is applied?
Yes.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> Hi all,
>>
>> As of now, file access functions in genfile.c can only be used by
>> superusers. This proposal is to relax those functions so as
>> replication users can use them as well. Here are the functions aimed
>
On Wed, Sep 2, 2015 at 4:26 PM, Andres Freund wrote:
> I'm not following? Just write pg_read_prefetch(state->memtuples + 3 +
> readptr->current) and the corresponding version for tuplesort in the
> callsites?
Oh, I see. Maybe I'll do it that way when I pick this up in a little
while. I need to co
Michael Paquier writes:
> On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera
> wrote:
>> Michael Paquier wrote:
>>> The main argument for this change is that pg_rewind makes use of those
>>> functions, forcing users to use a superuser role when rewinding a
>>> node.
>> Can this piggyback on Stephen
On 09/03/2015 12:23 AM, Andres Freund wrote:
On 2015-09-02 14:31:35 -0700, Josh Berkus wrote:
On 09/02/2015 02:25 PM, Tomas Vondra wrote:
As I explained, spindles have very little to do with it - you need
multiple I/O requests per device, to get the benefit. Sure, the DBAs
should know how ma
On 2015-09-02 19:48:15 -0400, Tom Lane wrote:
> Just on general principles, this seems like a pretty horrid idea.
> To me replication privilege means the ability to transfer data out of
> the master, not to cause arbitrary state changes on the master.
It's not about the permission to trigger pg_re
On Wed, Sep 2, 2015 at 12:24 PM, Peter Geoghegan wrote:
> On Wed, Sep 2, 2015 at 7:12 AM, Andres Freund wrote:
>> On 2015-07-19 16:34:52 -0700, Peter Geoghegan wrote:
>> Hm. Is a compiler test actually test anything reliably here? Won't this
>> just throw a warning during compile time about an un
On Thu, Sep 3, 2015 at 8:59 AM, Andres Freund wrote:
> On 2015-09-02 19:48:15 -0400, Tom Lane wrote:
>> Just on general principles, this seems like a pretty horrid idea.
>> To me replication privilege means the ability to transfer data out of
>> the master, not to cause arbitrary state changes on
On 2015-09-03 01:59:13 +0200, Tomas Vondra wrote:
> That's a bit surprising, especially considering that e_i_c=30 means ~100
> pages to prefetch if I'm doing the math right.
>
> AFAIK queue depth for SATA drives generally is 32 (so prefetching 100 pages
> should not make a difference), 256 for SAS
On 2015-09-02 17:14:12 -0700, Peter Geoghegan wrote:
> On Wed, Sep 2, 2015 at 12:24 PM, Peter Geoghegan wrote:
> > On Wed, Sep 2, 2015 at 7:12 AM, Andres Freund wrote:
> >> On 2015-07-19 16:34:52 -0700, Peter Geoghegan wrote:
> >> Hm. Is a compiler test actually test anything reliably here? Won't
, On Wed, Aug 26, 2015 at 4:05 AM, Kouhei Kaigai wrote:
>> On 2015/08/26 16:07, Kouhei Kaigai wrote:
>> I wrote:
>> >> Maybe I'm missing something, but why do we need such a flexiblity for
>> >> the columnar-stores?
>>
>> > Even if we enforce them a new interface specification comfortable to RDBMS
On Wed, Sep 2, 2015 at 5:31 PM, Joe Conway wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/02/2015 05:25 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> But I'm not sure I like the idea of adding a server dependency on
>>> the ability to exec pg_controldata. That seems like it
On Wed, Sep 2, 2015 at 5:55 PM, Andres Freund wrote:
> On 2015-09-02 14:36:51 -0400, Robert Haas wrote:
>> On Wed, Sep 2, 2015 at 2:20 PM, Fabien COELHO wrote:
>> >> I'm wondering if percentages instead of weights would be a better
>> >> idea. That'd mean you'd be forced to be more careful when a
On Thu, Sep 3, 2015 at 5:22 AM, Robert Haas wrote:
> Still, that's not a reason not commit this, so done.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 2, 2015 at 6:56 PM, Bruce Momjian wrote:
> On Wed, Sep 2, 2015 at 02:41:46PM -0400, Robert Haas wrote:
>> 4. Therefore, I think that we should instead use logical replication,
>> which might be either synchronous or asynchronous. When you modify
>> one copy of the data, that change w
Micahel,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >> As of now, file access functions in genfile.c can only be used by
> >> superusers. This proposal is to relax those functions so as
> >> replicat
On Thu, Sep 3, 2015 at 2:30 AM, Alvaro Herrera wrote:
> Andres Freund wrote:
>> Isn't a full test with a separate initdb, create extension etc. a really
>> heavyhanded way to test this? I mean that's a test where the setup takes
>> up to 10s, whereas the actual runtime is in the millisecond range?
On Thu, Sep 3, 2015 at 12:38 AM, Andres Freund wrote:
> Isn't a full test with a separate initdb, create extension etc. a really
> heavyhanded way to test this? I mean that's a test where the setup takes
> up to 10s, whereas the actual runtime is in the millisecond range?
>
> Adding tests in this m
That doesn't match any of the empirical tests I did at the time. I posted
graphs of the throughput for varying numbers of spindles with varying
amount of prefetch. In every case more prefetching increases throuput up to
N times the single platter throuput where N was the number of spindles.
There
On 9/2/15 2:56 PM, Jim Nasby wrote:
On 9/2/15 2:17 PM, Alvaro Herrera wrote:
Michael Paquier wrote:
I haven't written yet a test case but I think that we could reproduce
that simply by having a relation referenced in the exception block of
a first function, calling a second function that itsel
On Thu, Sep 3, 2015 at 10:05 AM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera wrote:
> The replication role already has read-only access to everything
> (nearly?) in the PGDATA directory. The specific issue in this ca
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Sep 3, 2015 at 10:05 AM, Stephen Frost wrote:
> > * Michael Paquier (michael.paqu...@gmail.com) wrote:
> >> On Thu, Sep 3, 2015 at 4:52 AM, Alvaro Herrera wrote:
> > The replication role already has read-only access to everything
> > (n
On Thu, Sep 3, 2015 at 3:41 AM, Robert Haas wrote:
> 3. IIUC, Postgres-XC handles this problem by reducing at least
> volatile functions, maybe all functions, to constants. Then it
> generates an SQL statement to be sent to the data node to make the
> appropriate change. If there's more than one
On 2015/09/01 14:39, Satoshi Nagayasu wrote:
> On 2015/09/01 14:01, Tom Lane wrote:
>> Satoshi Nagayasu writes:
>>> On 2015/09/01 13:41, Peter Geoghegan wrote:
If you want to use the queryId field directly, which I recall you
mentioning before, then that's harder. There is simply no cont
On Thu, Sep 3, 2015 at 11:20 AM, Stephen Frost wrote:
> * Michael Paquier wrote:
>> 1) Use a differential backup to me, or the possibility to fetch a set
>> of data block diffs from a source node using an LSN and then re-apply
>> them on the target node. The major disadvantage of this approach is
>
On 09/02/2015 03:56 PM, Bruce Momjian wrote:
On Wed, Sep 2, 2015 at 02:41:46PM -0400, Robert Haas wrote:
4. Therefore, I think that we should instead use logical replication,
which might be either synchronous or asynchronous. When you modify
one copy of the data, that change will then be repli
On Wed, Sep 2, 2015 at 07:50:25PM -0700, Joshua Drake wrote:
> >Can you explain why logical replication is better than binary
> >replication for this use-case?
> >
>
> Selectivity?
I was assuming you would just create identical slaves to handle failure,
rather than moving selected data around.
On Wed, Sep 2, 2015 at 09:03:25PM -0400, Robert Haas wrote:
> > Can you explain why logical replication is better than binary
> > replication for this use-case?
>
> Uh, well, for the same reasons it is better in many other cases.
> Particularly, you probably don't want to replicate all the data o
On Thu, Sep 3, 2015 at 8:28 AM, Bruce Momjian wrote:
>
> On Wed, Sep 2, 2015 at 07:50:25PM -0700, Joshua Drake wrote:
> > >Can you explain why logical replication is better than binary
> > >replication for this use-case?
> > >
> >
> > Selectivity?
>
> I was assuming you would just create identica
On Thu, Sep 3, 2015 at 2:15 AM, Andres Freund wrote:
> On 2015-08-12 11:59:48 -0700, Jeff Janes wrote:
>> Attached patch does it that way. There was also a free-standing
>> CHECK_FOR_INTERRUPTS() which had no reason that I could see not be a
>> vacuum_delay_point, so I changed that one as well.
On 3 September 2015 at 05:10, Andres Freund wrote:
> On 2015-08-09 12:47:53 +1200, David Rowley wrote:
> > I took a bit of weekend time to finish this one off. Patch attached.
> >
> > A quick test shows a pretty good performance increase:
> >
> > create table ts (ts timestamp not null);
> > inser
On 3 September 2015 at 07:24, Peter Geoghegan wrote:
> On Wed, Sep 2, 2015 at 7:12 AM, Andres Freund wrote:
> > What worries me about adding explicit prefetching is that it's *highly*
> > platform and even micro-architecture dependent. Why is looking three
> > elements ahead the right value?
>
>
On Wed, Sep 2, 2015 at 9:43 PM, David Rowley
wrote:
> Peter, would you be able to share the test case which you saw the speedup
> on. So far I've been unable to see much of an improvement.
The case I tested was an internal sort CREATE INDEX. I don't recall
the exact details, but testing showed it
On 2015/09/03 9:41, Robert Haas wrote:
That having been said, I don't entirely like Fujita-san's patch
either. Much of the new code is called immediately adjacent to an FDW
callback which could pretty trivially do the same thing itself, if
needed.
Another idea about that code is to call that c
On Wed, Sep 2, 2015 at 9:04 PM, Oleg Bartunov wrote:
>
>
>
> One lesson from XL we got is that we need testing framework for cluster,
> so any cluster project should at least pass functional and performance
> testing.
>
+1. In early XC days, we focused a lot on adding newer features and
supporti
>> One lesson from XL we got is that we need testing framework for cluster,
>> so any cluster project should at least pass functional and performance
>> testing.
>>
>
> +1. In early XC days, we focused a lot on adding newer features and
> supporting as many PG features as possible. That took its t
My AIX buildfarm members have failed the BinInstallCheck step on and off since
inception. It became more frequent when I added animals sungazer and tern
alongside the older hornet and mandrill. The animals share a machine with
each other and with dozens of other developers. I setpriority() the a
101 - 153 of 153 matches
Mail list logo
