ogic back unless
we have proof that this change make it better.
Patch is attached. I tried to make some comments, but probably they are
not enough.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
put-buffer-usagecount–logic–back.patch
On Fri, Feb 3, 2017 at 8:01 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Unfortunately, I have no big enough Power machine at hand to reproduce
> that results. Actually, I have no Power machine at hand at all. So,
> lwlock-power-2.patch was written "bli
eone would help me with testing and benchmarking.
1. https://www.postgresql.org/message-id/CAPpHfdsogj38HTDhNMLE56uJy9N8-
=gya2nnuwbpujgp2n1...@mail.gmail.com
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
lwlock-power-1.patch
Descripti
nly pgbench results on 72 physically cores Intel server are attached.
It quite similar to results I posted before, but it's curious that
performance degradation of master on high concurrency became larger.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Pos
-0mW6M03St7A%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/flat/CALxAEPuGpAjBSN-PTuxHfuLLqDS47BEbO_ZYxUYQR3ud1nwbww%40mail.gmail.com
[3] https://developers.google.com/open-source/gsoc/timeline
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ly update) tuple routing for foreign partitions
- hash partitioning
- not scanning the parent
Time is growing short, but it would
> be great to polish this a little more before we ship it.
>
Yes. Getting at least some of this features committed to v10 would be great
and improve partitioning usabi
kers will get free admission to the conference (all
days), tickets to Moscow and accommodation booked and paid by the
organizers.
We will be glad to see you in Moscow!
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
. But I don't like this
approach.
If we have large enough index scan, then we could either run out of cache
or consume too much memory
for that cache.
So, I think storing visibility information in index tuple is great for
regular index scans too. At least,
it allow us to evade #2 problem. That is great by itself.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
are just different kind of maps. And they could implement the same
interface. Imagine you can select between heap-organized table
and index-organized table just by choosing its primary access method. If
you select heap for primary access method, indexes would
refer TID. If you select btree o
On Wed, Oct 19, 2016 at 12:53 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 18 October 2016 at 23:46, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
>
> > Then vacuum removes (0;1) from heap, reference to (0;1) from tbl_pk_idx.
> > But ho
But it seems like rather better design for me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Oct 19, 2016 at 12:21 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Oct 18, 2016 at 9:28 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>
> wrote:
>
>> Vacuuming presents an additional challenge: in order to remove index
>> items from
ted this yet.
>
Imagine another situation: PK column was not updated, but indirect indexed
column was updated.
Thus, for single heap tuple we would have single PK tuple and two indirect
index tuples (correct me if I'm wrong).
How are we going to delete old indirect index tuple?
--
On Fri, Apr 8, 2016 at 10:09 PM, Peter Geoghegan <p...@heroku.com> wrote:
> On Wed, Mar 30, 2016 at 8:02 AM, Alexander Korotkov
> <aekorot...@gmail.com> wrote:
> > Hmm... I'm not completely agree with that. In typical usage partial sort
> > should definitely use
; Attached is a graph with the results. Full results are available at
>> https://hlinnaka.iki.fi/temp/csn-4-results/. In short, the patch
>> improved throughput, measured in TPS, with >= 32 or so clients. The
>> biggest difference was with 44 clients, which saw about 5% improvement.
>&g
vacuum of
single index.
But pointing each worker at separate index seems to be fair enough for
majority of cases.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Aug 22, 2016 at 12:09 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> I took a look at your patch. Couple of notes from me.
>
> const char *
>> GetEventIdentifier(uint16 eventId)
>> {
>> const char *res;
>> switch (eventId)
&
EventIdentifier seems too general name for me, isn't it? Could we name it
WaitEventIdentifier? Or WaitEventId for shortcut?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, Aug 19, 2016 at 3:19 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Fri, Aug 19, 2016 at 11:42 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > Hackers,
> >
> > originally this idea was proposed by Andres Freund while experimenting
On Fri, Aug 19, 2016 at 4:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> > originally this idea was proposed by Andres Freund while experimenting
> with
> > lockfree Pin/UnpinBuffer [1].
> > The
performance regression
in other cases. At least we should test read-write and smaller machines.
Any other ideas?
1.
https://www.postgresql.org/message-id/20160411214029.ce3fw6zxim5k6...@alap3.anarazel.de
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres
flexibility yet without adding a branch
> point in the code?
>
It's impossible without branch point in code. The question is where this
branch should be located.
In particular, be can put this branch point into planner by defining
distinct executor nodes for each pluggable storage. In this
r index scan too.
> Probably it
> > worth to discuss the way to normalize index expressions and clauses and
> work
> > out more convenient way to match them.
>
> pg_operator.oprcommutative ?
Do you mean pg_operator.oprcom?
In these examples we're also lacking of pg_operator.oprasso
indexes and so on). But imperative was that it should have its own
executor nodes,
and it doesn't have to compatible with existing index access methods.
Therefore, I think my design presented at PGCon and your current proposal
are
about orthogonal features which could coexist.
--
Alexander
On Fri, Aug 12, 2016 at 3:15 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> I'm now exploring code working with heap tuples. The following code
> in heap_update() catch my eyes.
>
> if (DoesMultiXactIdConflict((MultiXactId) xwait, infomask,
>> *lockmode))
&
a buffer
pin and vacuum would wait for pin release. But other heap operations could
still call heap_page_prune() which correspondingly can relocate tuple.
Probably, I'm missing something...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Aug 10, 2016 at 8:26 PM, Greg Stark <st...@mit.edu> wrote:
> On Wed, Aug 10, 2016 at 5:54 PM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > Oh, I found that I underestimated complexity of async commit... :)
>
> Indeed. I think Tom's attitude
ould take a hit. But I think that would be
> acceptable.
Oh, I found that I underestimated complexity of async commit... :)
Do I understand right that now async commit right as follows?
1) Async transaction confirms commit before flushing WAL.
2) Other transactions sees effect of async transaction only when its WAL
flushed.
3) In the session which just committed async transaction, effect of this
transaction is visible immediately (before WAL flushed). Is it true?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
s just an idea without any
proof so soon.
2) We already have functionality which trades insight into database with
way more huge overhead. auto_explain.log_analyze = true can slowdown
queries *in times*. Do you think we should remove it?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
at we do not have such accurate
> tests now?
>
Do you think that large shared buffers is a kind a stress test for wait
events monitoring? If so, why?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ake async commits to work.
>
I didn't get async commits problem at first glance. AFAICS, the difference
between sync commit and async is only that async commit doesn't wait WAL
log to flush. But async commit still receives LSN.
Could you describe it in more details?
--
A
an XID array.
FYI, I'm still fan of idea to rewrite XID with CSN in tuple in the same way
we're writing hint bits now.
I'm going to make prototype of this approach which would be enough for
performance measurements.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
inserts
> faster and to enable new advanced page layouts in indices.
>
+1 for PageReplaceItem()
Even if item is not the same size, we can move the tail of page once
instead of twice.
I think you should implement PageReplaceItem() version and add it to the
commitfest.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ages.
For data pages we have to reinitialize database cluster to enable
checksums. I think we can also require reinitialization to enable checksums
of SLRU pages. Thus, major problem would be that number of items fitting to
page would depend on whether checksums are enabled. However, it sho
scalability issues including high ProcArrayLock contention.
References.
1.
http://www.postgresql.org/message-id/CAPpHfdsytkTFMy3N-zfSo+kAuUx=u-7jg6q2byb6fpuw2cd...@mail.gmail.com
2.
http://www.postgresql.org/message-id/20151211130413.go14...@awork2.anarazel.de
3.
http://www.po
On Sun, May 22, 2016 at 12:39 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Mon, Mar 28, 2016 at 4:35 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> Hackers,
>>
>> one our customer meet near xid wraparound situation. xid cou
On Mon, Mar 28, 2016 at 2:05 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> After some debugging I found that vac_truncate_clog consumes xid just to
> produce warning. I wrote simple patch which replaces
> GetCurrentTransactionId() with ShmemVariabl
>
I've checked GIN code. Have no idea of how such wal record could be
generated...
The only idea I have is to add check that we're inserting valid WAL record
immediately before XLogInsert().
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
could package up a
> data directory after the issue hit?
>
FWIW, I'm also trying to reproduce it on big x86 machine on 9888b34f.
I'll write about results when get any.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
to touch some WAL we just applied? If the former, does
> Kevin's new code allow us to do the later?
That makes sense for me. If we could improve read-only queries on slaves
this way, Kevin's new code becomes much more justified.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
id you use for these tests: power-8 or x86? How long was
single run?
Per-run variation seems quite high. It also seems that it depends on which
version runs first. But that could be a coincidence.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
usly not a 9.6
> topic at this point, but it'd probably be good to that early in 9.7.
>
+1
Also, what do you think about validation script which checks consistency
between them?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
m
the syntax side it very looks like defining something boxes regions for two
keys which could be replacement for subpartitioning. But it isn't so.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
there is small regression. I think this
regression could be caused by alignment of other data structures.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
1116256 1167681
130 1066475 1120891
140 1040379 1085904
150 974064 1022160
160 938396 976487
170 953636 978120
180 920772 953843
We can see small but certain regression after snapshot too old feature.
--
Alexander Korotkov
Postgres Professional: http://www.postgre
On Tue, Apr 12, 2016 at 5:12 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Tue, Apr 12, 2016 at 3:48 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Tue, Apr 12, 2016 at 12:40 AM, Andres Freund <and...@anarazel.de>
>> wrote:
On Tue, Apr 12, 2016 at 6:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> > I agree with both of these ideas. Patch is attached.
>
> Pushed with minor cleanup.
>
Great, thanks!
--
Alexander Korotk
On Tue, Apr 12, 2016 at 6:34 PM, Teodor Sigaev <teo...@sigaev.ru> wrote:
> I agree with both of these ideas. Patch is attached.
>>
>
> Hmm, you accidentally forget to change flag type of GenericXLogRegister in
> contrib/bloom signature.
Fixed.
--
Alexander Korotk
st doing the
> byte-by-byte delta calculation.
I agree with both of these ideas. Patch is attached.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
generic-xlog-register.patch
Description: Binary data
--
Sent via pgsql-hackers mai
trouble?
>
Attached patch is intended to fix this. It zeroes "hole" in both
GenericXLogFinish() and generic_redo().
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
generic-xlog-zero-gap.patch
Description: Binary data
--
Sent via pgs
s from this logical slot. Logical slot position should be also
advanced on checkpoint.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ment.
We have not so many PGXACTs to care about bytes wasted to padding. But
could it have another negative side-effect?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Apr 11, 2016 at 5:04 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund <and...@anarazel.de> wrote:
>
>> Could you retry after applying the attached series of patches?
>>
>
> Yes, I will try wit
On Mon, Apr 11, 2016 at 4:27 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>
wrote:
> Alexander Korotkov wrote:
> > Kevin,
> >
> > This commit makes me very uneasy. I didn't much care about this patch
> > mainly because I didn't imagine its consequences. Now, I se
t so much. You need
> to make sure that the last two bytes of the page special space contain a
> uniquely identifiable code; compare spgist_page_id in SPGiST indexes.
>
Thank you for spotting these issues.
I'm going to prepare patches for fixing both of them.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Apr 11, 2016 at 8:10 AM, Andres Freund <and...@anarazel.de> wrote:
> On 2016-04-10 09:03:37 +0300, Alexander Korotkov wrote:
> > On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov <
> > a.korot...@postgrespro.ru> wrote:
> >
> > > On S
On Sun, Apr 10, 2016 at 2:24 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Sun, Apr 10, 2016 at 11:33 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov <
>> a.korot...@postgrespro.r
reverted - 1 065 732.6 TPS
So, for read-only benchmark this patch introduces more than 5 times
regression on big machine.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ount change. This is exactly what I meant by
> "someone identifies a way to realize similar coverage with lower duration."
> Thanks for contributing this study.
+1, row count reduction is a good to reduce regression test time.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Apr 10, 2016 at 8:36 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sat, Apr 9, 2016 at 10:49 PM, Andres Freund <and...@anarazel.de> wrote:
>
>>
>>
>> On April 9, 2016 12:43:03 PM PDT, Andres Freund <and...@anarazel.de>
On Sun, Apr 10, 2016 at 7:26 AM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Sun, Apr 10, 2016 at 1:13 AM, Andres Freund <and...@anarazel.de> wrote:
>
>> On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote:
>> > There are results with 5364b357 reverted.
On Sat, Apr 9, 2016 at 10:49 PM, Andres Freund <and...@anarazel.de> wrote:
>
>
> On April 9, 2016 12:43:03 PM PDT, Andres Freund <and...@anarazel.de>
> wrote:
> >On 2016-04-09 22:38:31 +0300, Alexander Korotkov wrote:
> >> There are results with 5364b3
On Sat, Apr 9, 2016 at 11:24 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Apr 8, 2016 at 10:19 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Fri, Apr 8, 2016 at 7:39 PM, Andres Freund <and...@anarazel.de
On Fri, Apr 8, 2016 at 10:19 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Apr 8, 2016 at 7:39 PM, Andres Freund <and...@anarazel.de> wrote:
>
>> As you can see in
>>
>
>> http://archives.postgresql.org/message-id/CA%2BTgmoaeRbN%3
> move to SF. I'd be glad if you would allow me to look over the patch
> > again, before pushing it sometime this weekend; this stuff is subtle,
> > and I'm not exactly my best right now.
>
> In view of these circumstances, the RMT has voted to extend the
> deadline for this parti
On Fri, Apr 8, 2016 at 7:39 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2016-04-07 16:50:44 +0300, Alexander Korotkov wrote:
> > On Thu, Apr 7, 2016 at 4:41 PM, Andres Freund <and...@anarazel.de>
> wrote:
> >
> > > On 2016-03-31 2
On Thu, Apr 7, 2016 at 4:41 PM, Andres Freund <and...@anarazel.de> 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
On Tue, Apr 5, 2016 at 5:45 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2016-04-05 17:36:49 +0300, Alexander Korotkov wrote:
> > Could the reason be that we're increasing concurrency for LWLock state
> > atomic variable by placing queue spinlock there?
>
> Do
for LWLock state
atomic variable by placing queue spinlock there?
But I wonder why this could happen during "pgbench -S", because it doesn't
seem to have high traffic of exclusive LWLocks.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
goto away;
>
> In general I don't have anything against goto. But are you sure that
> using it here is really justified?
Fixed with small code duplication which seems to be better than goto.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian P
On Thu, Mar 31, 2016 at 8:21 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
>
> I think these changes worth running benchmark again. I'm going to run it
> on 4x18 Intel.
>
The results are following.
clients master v3 v5 v9
1 11671 12507
ruct
> > +{
> > + int spins;
> > + int delays;
> > + int cur_delay;
> > + Pointer ptr;
> > + const char *file;
> > + int line;
> > +} SpinDel
Hi!
On Thu, Mar 31, 2016 at 4:59 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Tue, Mar 29, 2016 at 10:52 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> Hi, Andres!
>>
>> Please, find next revision of patch in attac
) BloomBuildState is explicitly zeroed.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
0002-generic-xlog.15.patch
Description: Binary data
0003-bloom-contrib.15.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
t that we should try and make every small sort done by the
> partial sort a quicksort. Which I think is a good idea. The common
> case is that groups are small, but the qsort() insertion sort will be
> very very fast for that case.
>
I'm not sure that in partial sort we should estimate sortin
>
> > I set that, but after that it hangs, even Initdb hangs..
>
> Yea, as Tom pointed out that's not going to work. I'll try to write a
> patch for approach 1).
>
Great! Do you need any improvements for pinunpin-cas-7.patch from me?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Mar 29, 2016 at 8:34 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Mar 29, 2016 at 8:29 PM, Teodor Sigaev <teo...@sigaev.ru> wrote:
>
>> I incorporated your changes and did some additional refinements on top of
>>> them
>>>
exposing it. If not, default assumption is
that this information shouldn't be exposed.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
comments to
generic_xlog.c. I'm not fan of duplicating things. What about moving
interface description from comments to docs completely?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
this can be marked "ready for
> committer". Will you have that ready soon?
>
Yes, that's it. I'm working on it now. I'm going to post it until
tomorrow.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Mar 29, 2016 at 6:20 PM, David Steele <da...@pgmasters.net> wrote:
> On 3/28/16 1:26 PM, Alvaro Herrera wrote:
>
>> Alexander Korotkov wrote:
>>
>>> On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera <
>>> alvhe...@2ndquadrant.com>
>>
On Sun, Mar 27, 2016 at 4:31 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sun, Mar 27, 2016 at 3:10 PM, Andres Freund <and...@anarazel.de> wrote:
>
>> On 2016-03-27 12:38:25 +0300, Alexander Korotkov wrote:
>> > On Sat, Mar 26, 2016 at 1:26 AM,
gt; that...
>>
>>
> I did only cursory review on the bloom contrib module and don't really
> have complaints there, but I know you can review that one. I'd like the
> English of the generic_xlog.c description improved but I won't get to it
> before weekend.
What is your
Xid. That
completely fixes this situation for me: ShmemVariableCache was successfully
updated.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix_vac_truncate_clog_xid_consume.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsq
d mark it
> "ready for committer" since I doubt any more reviewers will sign on this
> late in the CF.
>
I've checked the last version of the patch. Patch applies cleanly on
master, builds without warnings, regression tests pass.
The issue I reported about tsquery textual representation is fixed.
I'm going to mark this "Ready for Committer".
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sun, Mar 27, 2016 at 3:10 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2016-03-27 12:38:25 +0300, Alexander Korotkov wrote:
> > On Sat, Mar 26, 2016 at 1:26 AM, Alexander Korotkov <
> > a.korot...@postgrespro.ru> wrote:
> >
> > > Thank you very
On Sat, Mar 26, 2016 at 1:26 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> Thank you very much for testing!
> I also got access to 4 x 18 Intel server with 144 threads. I'm going to
> post results of tests on this server in next Monday.
>
I've run pgbench tes
Hi, Dilip!
On Fri, Mar 25, 2016 at 8:32 PM, Dilip Kumar <dilipbal...@gmail.com> wrote:
> On Fri, Mar 25, 2016 at 8:09 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> Could anybody run benchmarks? Feature freeze is soon, but it would be
>> *very
;>
>
> Do you know when you'll have a chance to respond to reviews and provide a
> new patch?
>
> Time is short and it's not encouraging that you say there is "still much
> work to be done". Perhaps it would be best to mark this "returned with
> feedback&quo
On Tue, Mar 22, 2016 at 1:08 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Mar 22, 2016 at 7:57 AM, Dilip Kumar <dilipbal...@gmail.com>
> wrote:
>
>>
>> On Tue, Mar 22, 2016 at 12:31 PM, Dilip Kumar <dilipbal...@gmail.com>
>&g
th these issues.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix-pg_dump-comment.patch
Description: Binary data
fix-am-tab-complete.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
significant infrastructural changes. It just
change some well-isolated placed.
Let's give it a chance. I've signed as additional reviewer and I'll do my
best in spotting all possible issues in this patch.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
, it's too late to include
something new to 9.6. This is why I've rework it and publish at github as
an extension for 9.6: https://github.com/postgrespro/pg_wait_sampling/
Hopefully, it could be considered as contrib for 9.7.
--
Alexander Korotkov
Postgres Professional: http
On Tue, Mar 22, 2016 at 11:53 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>
wrote:
> Alexander Korotkov wrote:
> > On Tue, Mar 22, 2016 at 1:26 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
>
> > > I noticed this state of affairs because I
Hi, Tomas!
On Mon, Mar 21, 2016 at 2:39 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Mar 18, 2016 at 1:20 PM, Dean Rasheed <dean.a.rash...@gmail.com>
> wrote:
>
>> Probably a better URL to give is
>> http://www.adellera.it/investigations
uming most of proacl values are NULLs when
you change it, acl wouldn't be dumped since NULL <> value IS NULL.
In general, these checks using subqueries looks complicated for me, hard to
validate and needs a lot of testing. Could we implement function "bool
need_acl_dump(oid objoid, o
ot intended to it so because it would significantly complicate
code. It's not yes clear that traffic in this place is high enough to make
such optimizations.
Since v4 patch implements slightly different approach. Could you please
test it? We need to check that this approach worth putting more ef
> testing.
Did you already fix the issues above or do you need me to fix them?
> Particularly I would like to understand the relcache issues to
> figure out whether the current one is right.
Good point. I'll also try to find relcache issues.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
n_dependency_type FUNCTION
function_with_argtypes
{
AlterExtensionContentsStmt *n = makeNode(AlterExtensionContentsStmt);
n->extname = $3;
n->action = $4;
n->objtype = OBJECT_FUNCTION;
n->objname = $7->funcname;
n->objargs = $7->funcargs;
n->deptype = $5;
$$ = (Node *)n;
}
I didn't try it. Probably it causes a grammar conflicts. In this case I
don't insist on it.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
( 'nyc' | 'big' & 'appl' | 'new' & 'york' ) & 'citi' & 'foo' & ( 'bar' |
'qq' )
(1 row)
select rewrite( ARRAY['moscow', keyword, sample] ) from test_tsquery;
However, such reorderings look unclear and need motivation.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
201 - 300 of 1043 matches
Mail list logo
