have a Server Status file that shows Standby or Master,
obviously not updated on crash.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
sgage_id in my patch is
> just what offers the pre-translated error text to plugins.
OK, now I understand the patch, I am happy to apply it.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
. That would allow people to identify
messages without relying on people labelling everything correctly, as well
as writing filters that do not depend upon language.
I'm guessing this would require making the pre-translated error text
available to plugins as well as translated form.
--
Simon Rigg
sily
map old to new. Why choose to break all extensions that do this? We could
easily keep this by making the old API assign locks out of a chunk called
"Old Extension API". Deprecate the old API and remove in a later release.
Like pretty much every other API we support.
We must respect
ents record how many workers were available during
execution?
Is there a way to prevent execution if too few parallel workers are
available?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ages into the shutdown sequence.
>
> [ shrug... ] I won't stand in the way of someone else figuring out
> what makes sense there, but I don't intend to do it; and I don't think
> that the quick hacks I did over the last couple days make a reasonable
> basis for a permanent patch.
&g
r at some much
> smaller other value.
>
Hmm, looks like the != part attempted to wrap, but just didn't get it right.
Your patch looks right to me, so I will commit, barring objections... with
backpatch. Likely to 9.0, AFAICS.
--
Simon Riggshttp://www.2ndQuadrant.com/
<
a small number of blocks remaining we don't spend hours
performing them. Allowing very large values would make that even more
strange.
I would put a limit of 100,000 seconds = 27 hours.
Some systems offer a recovery_time_objective setting that is used to
control how frequently checkpoints occur
be
solved. We don't usually discuss that option here, since this is an
engineering list.
Since you've written the email here, I'd ask that you join our community
and use your knowledge and passion to make things happen.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
se people?
>
Logical messages
Generic WAL records
Seems like I can tell them apart. Worth checking, but I think we're OK.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ckup or replication.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed in a
later release.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t;
> So +1 from me to checking for infinity.
>
+1
ERROR infinite result sets are not supported, yet
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 22 January 2016 at 05:07, Noah Misch <n...@leadboat.com> wrote:
> On Wed, Jan 20, 2016 at 06:58:24PM +0000, Simon Riggs wrote:
> > The main problem is the length of the integration phase, which is mostly
> > where nothing happens.
>
> The open items wiki page saw
are involved in producing and
maintaining PostgreSQL. Whether the names are properly attributed will
always be a time-consuming task, but I will oppose any attempt to remove or
obscure evidence of who develops PostgreSQL, wherever that occurs.
--
Simon Riggshttp://www.2ndQuadran
On 21 January 2016 at 16:31, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Jan 1, 2016 at 7:50 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> > Failover Slots
> > In the current patch, any slot defined on a master will generate WAL,
> > leading to a
ularly relevant
> imo. Additionally, afaics, it will only ever be 0 or 1.
>
Even better, we could make it add >1
> I think we should either remove that part of the log output, or make it
> display the number of segments added since the beginning of the
> checkpoint.
>
e scan of pending list is O(N).
If we did the same thing for monotonic inserts into a btree, the
performance of ruling out any contents in the pending list would be O(1),
so it is more feasible than you say.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 5 January 2016 at 06:45, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 4 January 2016 at 20:44, Alvaro Herrera <alvhe...@2ndquadrant.com>
> wrote:
>
>
>> Maybe
>> there are more ALTER TABLE subcommands that should be setting something
>> up? In case
> >
> > Does this mean that standby.h also needs to get parts spun off into a
> > new standbydef.h that can be included from front-end code?
>
>
> That is how I've done it.
>
> The lock cancel patch applies over the header split patch.
>
This looks good to me,
.
>
You are right; search within this buffer is O(log(N)). But we can test
whether we need to search in the buffer at all with O(1).
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ace dev meeting to discuss this if we are going to
discuss it here?
ISTM the wrong starting point to discuss plans in an unplanned way and
assume that everyone has time to take part today, right now.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Postgre
early. Let's
get back on track and release on time (Sept).
The main problem is the length of the integration phase, which is mostly
where nothing happens. We need to manage that process just as we do with
CFs.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 20 January 2016 at 19:45, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Jan 20, 2016 at 2:26 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > and...@anarazel.de (Andres Freund) writes:
> >> On 2016-01-20 18:53:54 +, Simon Riggs wrote:
> >>> Wha
al.
If we believe in "peer review", we need peers that review.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
; Our current 9.5/9.6 timing looks more like the 8.X series of release
> dates. Everyone might be fine with that, but we had better be prepared
> for November-February major release dates going forward.
>
I don't mind what month we pick, as long as we stick to the schedule.
--
Simon Ri
On 20 January 2016 at 20:29, Joshua D. Drake <j...@commandprompt.com> wrote:
> On 01/20/2016 10:53 AM, Simon Riggs wrote:
>
>> On 20 January 2016 at 15:40, Bruce Momjian <br...@momjian.us
>> <mailto:br...@momjian.us>> wrote:
>>
>> Many people
On 16 January 2016 at 02:10, Noah Misch <n...@leadboat.com> wrote:
> On Wed, Jan 13, 2016 at 12:13:11PM -0500, Tom Lane wrote:
> > Simon Riggs <si...@2ndquadrant.com> writes:
> > > On 13 January 2016 at 14:48, Noah Misch <n...@leadboat.com> wrote:
> >
On 13 January 2016 at 14:48, Noah Misch <n...@leadboat.com> wrote:
> I've noticed commits, from a few of you, carrying pgindent changes to lines
> the patch would not otherwise change.
Could we review again why this matters?
--
Simon Riggshttp://www.2ndQuadran
On 12 January 2016 at 05:58, Michael Paquier <michael.paqu...@gmail.com>
wrote:
> On Tue, Jan 12, 2016 at 6:35 AM, Simon Riggs wrote:
> > Comments in xlog.c say
> >
> > "In addition to the shared variable, each backend has a private copy of
> > LogwrtRe
On 12 January 2016 at 06:35, Michael Paquier <michael.paqu...@gmail.com>
wrote:
> On Tue, Jan 12, 2016 at 4:57 AM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> > Performance tests for me show that the patch is effective; my results
> match
> > Jesper's roughl
sensible and useful to be notified of this as a condition the
operator would wish to know about. The message doesn't recur every
checkpoint, it occurs only once at the point the files are created, so its
not log spam either.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2nd
On 12 January 2016 at 18:14, Andres Freund <and...@anarazel.de> wrote:
> Hi,
Thank you for the additional review.
> On 2016-01-11 19:39:14 +, Simon Riggs wrote:
> > Currently, the patch reuses all of the code related to reading/write
> state
> > files, so it is
On 12 January 2016 at 12:53, Michael Paquier <michael.paqu...@gmail.com>
wrote:
> On Tue, Jan 12, 2016 at 5:21 PM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> > Should we just move the code somewhere just to imply it is generic? Seems
> > pointless
On 11 January 2016 at 20:10, Andres Freund <and...@anarazel.de> wrote:
> On January 11, 2016 8:57:58 PM GMT+01:00, Simon Riggs
> <si...@2ndquadrant.com> wrote:
> >On 11 January 2016 at 18:43, Simon Riggs <si...@2ndquadrant.com> wrote:
>
> >It's cl
On 11 January 2016 at 01:46, Robert Haas <robertmh...@gmail.com> wrote:
> /me crawls into a hole.
>
> Thanks.
Far from it, thanks very much for thinking about it.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Deve
On 11 January 2016 at 22:24, Andres Freund <and...@anarazel.de> wrote:
> Please wait till at least tomorrow evening, so I can have a meaningful
> look.
>
No problem, make sure to look at 2pc_optimize.v4.patch
--
Simon Riggshttp://www.2ndQuadrant.c
On 11 January 2016 at 23:11, Stas Kelvich <s.kelv...@postgrespro.ru> wrote:
> >
>
> On 11 Jan 2016, at 21:43, Simon Riggs <si...@2ndquadrant.com> wrote:
> >
> > Have you measured lwlocking as a problem?
> >
>
> Yes. GXACT locks that wasn’t even
lt, which is updated when convenient."
It is therefore valid to update the value of both Write and Flush positions
at the same time, any time either is required.
My suggested commit pattern for this is...
1. Update existing function to maintain LogwrtResult more eagerly (separate
On 11 January 2016 at 12:58, Stas Kelvich <s.kelv...@postgrespro.ru> wrote:
>
> > On 10 Jan 2016, at 12:15, Simon Riggs <si...@2ndquadrant.com> wrote:
> >
> > So we've only optimized half the usage? We're still going to cause
> replication delays.
>
> Y
On 11 January 2016 at 14:38, Alvaro Herrera <alvhe...@2ndquadrant.com>
wrote:
> * Simon Riggs
> Fix handling on XLOG_RUNNING_XACTS generated by bgwriter on idle
> systems
>
> I assume this means they intend to commit them in some reasonable
> timeframe (po
as to be done
> on a standby. This way we'll need no extra wal flushes and fsyncs.
>
Feel free to submit a patch that does that.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11 January 2016 at 18:51, Jesper Pedersen <jesper.peder...@redhat.com>
wrote:
> On 01/10/2016 04:15 AM, Simon Riggs wrote:
>
>> One concern that come into my mind while reading updated
>>> patch is about creating extra bool field in GlobalTransactionData
>>
On 11 January 2016 at 18:43, Simon Riggs <si...@2ndquadrant.com> wrote:
> I'm looking to commit what we have now.
>
Here is the patch in its "final" state after my minor additions, edits and
review.
Performance tests for me show that the patch is effective; my results
On 11 January 2016 at 19:03, Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2016-01-09 15:29:11 +0000, Simon Riggs wrote:
> > Hmm, I was just preparing this for commit.
>
> Just read downthread that you want to commit this soon. Please hold of
> for a while,
ke we should be fixing both.
We can either
1) Skip fsyncing the RecreateTwoPhaseFile and then fsync during
restartpoints
2) Copy the contents to shmem and then write them at restartpoint as we do
for checkpoint
(preferred)
> > On 09 Jan 2016, at 18:29, Simon Riggs <si...@2ndquadrant.com> wrot
On 10 January 2016 at 16:32, Robert Haas <robertmh...@gmail.com> wrote:
> On Sat, Jan 9, 2016 at 5:13 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
> > Avoid pin scan for replay of XLOG_BTREE_VACUUM
> > Replay of XLOG_BTREE_VACUUM during Hot Standby was prev
aces that probably requires more detailed
> description I’m ready
> to extend that.
>
Hmm, I was just preparing this for commit.
Please have a look at my mild edits and extended comments.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL
aces that probably requires more detailed
> description I’m ready
> to extend that.
>
Your comments say
"In case of crash replay will move data from xlog to files, if
that hasn't happened before."
but I don't see that in code. Can you show me where that happens?
--
On 8 January 2016 at 13:13, Vitaly Burovoy <vitaly.buro...@gmail.com> wrote:
> On 1/8/16, Simon Riggs <si...@2ndquadrant.com> wrote:
> > On 8 January 2016 at 12:49, Vitaly Burovoy <vitaly.buro...@gmail.com>
> > wrote:
> >
> >
> >> In Postg
seq
scan.
How does this help? The lock and scan times are the same.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
o I don't think it is worth applying this patch now. I should add that I
also had a patch that did this, posted earlier IIRC. That is not the reason
to reject this, just me pointing out that I'm effectively rejecting my own
earlier patch also.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
he
FuncCallContext, but currently that isn't enforced.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ion names, too, just in case.)
>
> The grammar fixes seem like a good thing to do in the long run, too,
> but there's little need to risk back-patching it since accepting
> col_name_keywords without quoting would be mostly a convenience issue.
All seems reasonable.
--
Simon Riggs
I think some additional tests wouldn't hurt.
>
Each subcommand message should be generated at least once in tests.
> I await feedback from Simon Riggs, who set himself up as reviewer a
> couple of days ago. Simon, do you also intend to be committer? If so,
> please mark yourself as
On 21 December 2015 at 21:28, Alvaro Herrera <alvhe...@2ndquadrant.com>
wrote:
> Simon Riggs wrote:
> > During VACUUM of btrees, we need to pin all pages, even those where
> tuples
> > are not removed, which I am calling here the "pin scan". This is
> especi
backpatch is warranted because it is a severe performance issue with
replication and we can fix that before 9.5 hits the streets.
I'll be doing some more testing and checking, so not in a rush.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
is WIP, posted for comment, so you can see where I'm going.
I'm expecting to have a working version including timeline following for
9.6.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
and wraps around
every 4 billion transactions. However, these functions export a 64-bit
format that is extended with an "epoch" counter so it will not wrap around
during the life of an installation."
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
esting.
Do you have any comments on performance testing?
Are there any opportunities to improve Alfresco using the new features in
PostgreSQL 9.5?
Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 17 December 2015 at 16:00, Tomas Vondra <tomas.von...@2ndquadrant.com>
wrote:
> On 12/17/2015 11:44 AM, Simon Riggs wrote:
>
>>
>> My understanding is that the bloom filter would be ineffective in any of
>> these cases
>> * Hash table is too small
>>
On 21 December 2015 at 14:38, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Dec 21, 2015 at 8:06 AM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> > On 21 December 2015 at 12:54, Robert Haas <robertmh...@gmail.com> wrote:
> >>
> >> On
multiple passes for no reason...
>
> Since BRIN indexes cannot be primary keys nor unique keys, it's hard to
> be convinced that the use case of a table with only BRIN indexes is
> terribly interesting.
>
Given BRIN's characteristics, such a table design is compelling when the
table i
On 21 December 2015 at 09:35, Peter Geoghegan <p...@heroku.com> wrote:
> On Mon, Dec 21, 2015 at 1:24 AM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> > Given BRIN's characteristics, such a table design is compelling when the
> > table is very large, yet possi
llow unique values. This would be
similar to the way SQLServer compresses primary key indexes.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
which tuples are being removed. The
only thing it does is skip past the requirement to pin each of the
intervening blocks where nothing has happened.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, T
n discard it if
it would be ineffective.
My understanding is that the bloom filter would be ineffective in any of
these cases
* Hash table is too small
* Bloom filter too large
* Bloom selectivity > 50% - perhaps that can be applied dynamically, so
stop using it if it becomes ineffective
--
Simon Rigg
o store the LSN (8 bytes).
WAL is fsynced every time we finish writing a file, so we only actually
need to store the byte position within each file, so no more than 16MB.
That fits within a 4 byte value, so can be written atomically.
So I have a valid way forward for this approach. Cool.
ubsequent matching inner tuples, as none will exist.
>> * For semijoins unique_inner will always be true, although
>> * in this case we don't match another inner tuple as this
>> * is the required semi join behavior.
>> */
>>
>> Alternatively or additionally we can rename
tastrophe here. I think we can do it, but I think it needs these
things
* Clear notice that it is happening unconditionally and unavoidably
* Log files showing it has happened, action by action
* Very clear mechanism for resolving an incomplete or interrupted upgrade
process. Which VMs got upgraded? Whi
2. The quality of Postgres' cardinality estimates is not generally worse
> than that of the major commerical systems.
>
Good to hear, though we have found problems there that alter plan selection
adversely for TPC-H with the current optimizer. We have some improvements
which may be in the next
On 7 December 2015 at 16:44, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 6 December 2015 at 16:38, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> >> Lastly, in most cases knowing that t2.id <= 10 is just not worth all
>> >> that much; it's certainly
been working on Col
Store API for about 18 months and work on that continues with more
submissions for 9.6 due.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
emoved? Or perhaps
> replaced with the sequence's Oid in pg_class, since that'd be quite handy
> for logical decoding of sequences.
>
If the name is wrong then probably other fields are wrong also when we do
ALTER SEQUENCE?
We should add the fields you need, but don't alter anything in
F
to do was find simple answers, but that isn't the way life is. You ask for
a chain of logical thought, but it is for you to create one, somehow:
patches are default-reject, not committer-explain-why-reject.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&g
On 13 December 2015 at 11:02, Andres Freund <and...@anarazel.de> wrote:
> On December 13, 2015 10:19:07 AM CET, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> >I didn't see the patch for this anywhere. Where is the code?
>
> Where I'd the code for all of pg logical?
On 6 December 2015 at 17:39, Konstantin Knizhnik <k.knizh...@postgrespro.ru>
wrote:
> I have integrated pglogical_output in multimaster, using bdr_apply from
> BDR as template for implementation of receiver part.
>
I didn't see the patch for this anywhere. Where is the code?
ay, the license is yet to be determined, and it'll be Q1
> 2016. Yes, I've worked on open sourcing it.
>
If its under the Postgres licence and submitted to core, as is BDR, you may
find many people interested in working on it also.
Initial development of major features is IMHO best done by small groups
On 10 December 2015 at 18:59, Robert Haas <robertmh...@gmail.com> wrote:
Why did we make the change? I'm not sure it's bad, but
> it seems funny to whack a user-visible behavior around like this
> without a clearly-explained reason.
>
Surely the title of the post explains?
e.
I think we could do better still, but this looks like the easiest 80% and
actually removes code.
The lack of substantial comments on the patch is a problem though - the
details above should go in the patch. I'll have a go at reworking this for
you, this time.
--
Simon Riggshtt
array at relcache build time and invalidate relcache
when we extend. WAL log any extension to a new segment and write the table
to disk at checkpoint.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
is a
> small
> extension capable of retrieving the element type of an 'anyarray' object
> and
> recreating this particular 'anyarray' object using the 'array_in'
> procedure.
>
Please submit a patch on core for this.
--
Simon Riggshttp://www.2ndQuadrant.co
in some kind
of ordering depending upon the cost, so we are careful to balance the
cost/benefit of trying certain optimizations.
Optimizer directives might be useful also, but we can do just as well with
a heuristic.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
licitly instructed by the user. It Just Works.
We can decide what the heuristic limit is based upon the cost of the
technique. I don't think it matters how quick your CPU is, it matters how
long planning takes as a % of the whole expected execution time.
--
Simon Riggshttp://www.2ndQ
ay as well
have released it earlier.
I'm thinking about a two stage release process...
Stage 1 - released, but with caveats and some parts marked
experimental/beta whatever
Stage 2 - released, all caveats resolved
Not sure what to call that.
--
Simon Riggshttp://www.2ndQuadrant.c
d it this way and the other ways
you tried/decided not to pursue. Thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4 December 2015 at 16:29, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Simon Riggs <si...@2ndquadrant.com> writes:
> > On 1 December 2015 at 17:05, Robert Haas <robertmh...@gmail.com> wrote:
> >> do we want to
> >> back-patch those changes to 9.5 at
ch.
The other way to look at what you've said here is that you don't seem to
have a way of building the hash table in only one process, which concerns
me.
What I can confirm at this point is that
> I've thought about the problem you're asking about here, and that
> EnterpriseDB intends
ency, so its not useful in all cases.
I think having some kind of message queue between nodes would also help,
since there are many cases for which we want to transfer data, not just a
replication data flow. For example, consensus on DDL, or MPP query traffic.
But that is open to wider deba
pposite part of the pipe for pglogical_output -
> analog of receiver_raw?
>
Yes, there is. pglogical is currently in test and will be available
sometime soon.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ch I'll publish when I have more
time. I suggest this is a good idea, just needs some serious
committer-love, so we should bounce this for now.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ans we must either
use N * work_mem, or we must limit the hash table to work_mem / N per
partial plan.
How can the partial paths share a hash table?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
mbers rarely speak for themselves, without LSD. (Which
numbers?)
How are we doing here? Keen to see this work get committed, so we can move
onto parallel sort. What's the summary?
How about we commit it with a sort_algorithm = 'foo' parameter so we can
compare things before release of 9.6?
--
Simon Riggs
eter which we used to confirm
earlier sort improvements. I trust it will show this is good and can be
removed prior to release of 9.6.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t L ?
I don't really understand why parallel query was pursued in small pieces,
but partitioning needs to happen all in one huge patch. Wishing too many
things is going to slow down this feature.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> on.
>
+1
We don't have a message appear when hash joins use go weird, and we
definitely don't want anything like that for sorts either.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
for subtransactions as well.
>
The number of subxids is unbounded, so as you say, reserving shmem isn't
viable.
I'm interested in real world cases, so allocating 65 xids per process isn't
needed, but we can say is that the optimization shouldn't break down
abruptly in the presence of a small/
On 17 November 2015 at 11:48, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Tue, Nov 17, 2015 at 5:04 PM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
>
>> On 17 November 2015 at 11:27, Amit Kapila <amit.kapil...@gmail.com>
>> wrote:
>>
>
On 17 November 2015 at 00:52, Peter Geoghegan <p...@heroku.com> wrote:
> This patch does seem like a slam dunk, even if I do say so myself
Short and sweet! Looks good.
I would be inclined to add more comments to explain it, these things have a
habit of being forgotten.
--
Si
help there.
The hash table can also be used for lookups. My thinking is that most reads
of older xids are caused by long running transactions, so they cause a page
fault at commit and then other page faults later when people read them back
in. The hash table works for both kinds of page faul
On 15 November 2015 at 10:41, Simon Riggs <si...@2ndquadrant.com> wrote:
> So anyway, consider me nudged to finish my patch to provide capability
> for that by 1 Jan.
>
My earlier patch aimed to allow WALReceiver to wait on both a latch and a
socket as well as allow WALWriter t
601 - 700 of 8408 matches
Mail list logo
