On Wed, Feb 15, 2017 at 8:13 PM, Andres Freund wrote:
> I don't think general INSERTs are safe, if you consider unique indexes
> and foreign keys (both setting xmax in the simple cases and multixacts
> are likely to be problematic).
There's no real problem with setting xmax or creating multixacts
On 2017-02-15 20:35:16 -0500, Stephen Frost wrote:
> Perhaps, but until we've got a system worked out for having the workers
> do the writes, we aren't getting anything. Being able to have the
> leader do the writes based on the tuples fed back from the workers is
> clearly better than nothing.
N
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-02-15 20:28:43 -0500, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > On February 15, 2017 5:20:20 PM PST, Stephen Frost
> > > wrote:
> > > >In many cases, I expect this would work just as well, if not bette
On 2017-02-15 20:28:43 -0500, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@anarazel.de) wrote:
> > On February 15, 2017 5:20:20 PM PST, Stephen Frost
> > wrote:
> > >In many cases, I expect this would work just as well, if not better,
> > >than trying to actually do writes in paral
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On February 15, 2017 5:20:20 PM PST, Stephen Frost wrote:
> >In many cases, I expect this would work just as well, if not better,
> >than trying to actually do writes in parallel.
>
> Why? IPCing tuples around is quite expensive. Or do you m
On February 15, 2017 5:20:20 PM PST, Stephen Frost wrote:
>In many cases, I expect this would work just as well, if not better,
>than trying to actually do writes in parallel.
Why? IPCing tuples around is quite expensive. Or do you mean because it'll be
more suitable because of the possible p
All,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-02-15 08:48:44 -0500, Robert Haas wrote:
> > The other way of fixing this problem is to have each worker generate a
> > subset of the tuples and funnel them all back to the leader through a
> > Gather node; the leader then does all the ins
Hi,
On 2017-02-15 08:48:44 -0500, Robert Haas wrote:
> We got rid of the major existing use of page locks in
> 6d46f4783efe457f74816a75173eb23ed8930020, which extirpated them from
> hash indexes, and I was kind of hoping they could go away altogether,
> but we can't do that as long as GIN is using
On Thu, Feb 16, 2017 at 12:48 AM, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 12:24 AM, Joshua Chamberlain
> wrote:
> > Hello,
> >
> > (I'm posting to hackers since I got no response on the general list.)
> >
> > I use Postgres + PostGIS quite heavily, and recently have been taking
> full
> > a
On Wed, Feb 15, 2017 at 12:24 AM, Joshua Chamberlain wrote:
> Hello,
>
> (I'm posting to hackers since I got no response on the general list.)
>
> I use Postgres + PostGIS quite heavily, and recently have been taking full
> advantage of the new parallelism in 9.6. I'm now running queries in a few
On Tue, Feb 14, 2017 at 09:24:47PM -0800, Joshua Chamberlain wrote:
> Hello,
>
> (I'm posting to hackers since I got no response on the general
> list.)
>
> I use Postgres + PostGIS quite heavily, and recently have been
> taking full advantage of the new parallelism in 9.6. I'm now running
> quer
On Wed, Feb 15, 2017 at 2:24 PM, Joshua Chamberlain wrote:
> Are there plans in 10.0 to allow parallelism in queries that write, or at
> least in "CREATE TABLE AS" queries? (Support in materialized views would be
> great, too!)
Nope. There are no patches for now.
--
Michael
--
Sent via pgsql-
Hello,
(I'm posting to hackers since I got no response on the general list.)
I use Postgres + PostGIS quite heavily, and recently have been taking full
advantage of the new parallelism in 9.6. I'm now running queries in a few
hours that would otherwise take more than a day.
However, parallelism
13 matches
Mail list logo