CT a FROM GENERATE_SERIES(1,
1000) a;
You can achieve the same result by execution of single SQL statement.
INSERT INTO con_hash_index_table (keycol) SELECT (a - 1) % 1000 + 1 FROM
GENERATE_SERIES(1, 1002000) a;
Unless you have some special idea of doing this in 1002 separate
transactions.
-
to the
> alignment patch. Do we have evidence to commit both?
>
> Well, We have seen some regression in read-write test with pgxact
> alignment patch - [1]. I may need to run the test with both the
> patches to see the combined effect on performance.
>
> [1]
mark it as "ready for committer"?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
letely separate feature. And it should be posted and discussed
separately.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Mar 2, 2017 at 5:57 PM, David Steele <da...@pgmasters.net> wrote:
> Hi Alexander,
>
> On 2/16/17 11:20 AM, Robert Haas wrote:
> > On Thu, Feb 16, 2017 at 10:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> Robert Haas <robertmh...@gmail.com> wri
Hi all!
It seems that PostgreSQL has passed to GSoC mentoring organizations this
year!
https://summerofcode.withgoogle.com/organizations/4558465230962688/
Congratulations!
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Feb 21, 2017 at 1:47 PM, Bernd Helmle <maili...@oopsware.de> wrote:
> Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov:
> > I think it would make sense to run more kinds of tests. Could you
> > try set
> > of tests provided by Tomas Vondra?
WAL writes in a new
> cluster are a more expensive than in an old one, because of segment
> recycling.
>
+1
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
s me think that probably there is something
wrong in testing methodology.
Are you doing re-initdb and pgbench -i before each run? I would ask you to
do the both.
Also, if regression would still exist, let's change the order of versions.
Thus, if you run master before patched version, I would ask
Also patch has set of assorted code and comments improvements.
Links
1.
https://www.postgresql.org/message-id/CA+TgmoZapyHRm7NVyuyZ+yAV=u1a070bogre7pkgyraegr4...@mail.gmail.com
2.
https://www.postgresql.org/message-id/cam3swzql4yd2sndhemcgl0q2b2otdkuvv_l6zg_fcgoluwm...@mail.gmail.com
--
Alexand
On Fri, Feb 17, 2017 at 12:44 PM, Ashutosh Sharma <ashu.coe...@gmail.com>
wrote:
> >> On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov
> >> <a.korot...@postgrespro.ru> wrote:
> >> > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera
>
On Thu, Feb 16, 2017 at 4:58 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> &g
if needed). This way wouldn't be
that brief, but it is much more correct.
Also this like catch my eyes.
> info->amcanorderbyop = (void (*)()) amroutine->amcanorderbyop;
It's not necessary to use cast here. For instance, we don't use cast
for amcostestimate.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Feb 15, 2017 at 11:49 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Mon, Feb 13, 2017 at 8:02 PM, Ashutosh Sharma <ashu.coe...@gmail.com>
> wrote:
>
>> I too have performed benchmarking of this patch on a large machine
>> (with 12
/www.postgresql.org/message-id/20160822021747.u5bqx2xwwjzac...@alap3.anarazel.de
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
pgxact-align-3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Tue, Feb 14, 2017 at 3:57 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>
wrote:
> Alexander Korotkov wrote:
> > On Mon, Feb 13, 2017 at 7:07 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
>
> > > Re the coding of the padding computat
On Mon, Feb 13, 2017 at 10:17 PM, Tomas Vondra <tomas.von...@2ndquadrant.com
> wrote:
> On 02/13/2017 03:16 PM, Bernd Helmle wrote:
>
>> Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov:
>>
>>> Thus, I see reasons why in your tests absolute
On Mon, Feb 13, 2017 at 7:07 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>
wrote:
> Alexander Korotkov wrote:
>
> > Yes, influence seems to be low. But nevertheless it's important to
> insure
> > that there is no regression here.
> > Despite pg_prewarm'ing and r
ere:
>
> I've done some benchmarking of this patch against the E850/ppc64el
> Ubuntu LPAR we currently have access to and got the attached results.
> pg_prewarm as recommended by Alexander was used, the tests run 300s
> secs, scale 1000, each with a testrun before. The SELECT-
On Sat, Feb 11, 2017 at 4:17 PM, Tomas Vondra <tomas.von...@2ndquadrant.com>
wrote:
> On 02/11/2017 01:21 PM, Alexander Korotkov wrote:
>
>> Hi, Tomas!
>>
>> On Sat, Feb 11, 2017 at 2:28 AM, Tomas Vondra
>> <tomas.von...@2ndquadrant.com <mail
On Wed, Feb 8, 2017 at 5:00 PM, Bernd Helmle <maili...@oopsware.de> wrote:
> Am Dienstag, den 07.02.2017, 16:48 +0300 schrieb Alexander Korotkov:
> > But win isn't
> > as high as I observed earlier. And I wonder why absolute numbers are
> > lower
> > than in our
as big as used by Alexander (with 72
> physical cores), but it seems useful to verify the patch does not have
> negative impact on smaller machines.
>
> In particular I've ran these tests:
>
> * r/o pgbench
> * r/w pgbench
> * 90% reads, 10% writes
> * pgbench with s
tarting a new
> thread to make sure we collect all the relevant votes, but I really,
> really think it's past time for this to go away. The last actual
> change to tsearch2 which wasn't part of a wider cleanup was
> 3ca7eddbb7c4803729d385a0c9535d8a972ee03f in January 2009, so it's been
> 7 years since t
r project ideas
> submitted so we can include them.
>
Thank you for reminder. I added couple more project ideas and added me,
Oleg and Teodor to possible mentors of some projects.
That seems to be all that I have for now.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
On Tue, Feb 7, 2017 at 3:16 PM, Bernd Helmle <maili...@oopsware.de> wrote:
> Am Montag, den 06.02.2017, 22:44 +0300 schrieb Alexander Korotkov:
>
>2. Also could you run each test longer: 3-5 mins, and run them with
>variety of clients count?
>
>
> So here a
On Mon, Feb 6, 2017 at 8:28 PM, Bernd Helmle <maili...@oopsware.de> wrote:
> Am Montag, den 06.02.2017, 16:45 +0300 schrieb Alexander Korotkov:
> > I tried lwlock-power-2.patch on multicore Power machine we have in
> > PostgresPro.
> > I realized that using labels in as
because
that machine is used for tries to make Postgres work properly on AIX.
So, benchmarking help is very relevant. I would very appreciate that.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
lwlock-power-3.patch
Description: Binary d
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
and measure the time with it.
So If the performance is rather acceptable now I'd continue switch to
XML, and get back to the performance issues after the switch.
(epub generation is much more slow, and I have developed a patch to
speed up it too.)
Best regards,
Alexander
01.12.2016 19:49, Alvaro
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
Hello,
I thought it would be cool to have conditional check syntax, which gets
converted to simple check constraint syntax.
Here’s a gist:
https://gist.github.com/aj0strow/5a07f2ddcad324c4dac2c4095c821999
It’s just sugar, but i think it would make check constraints easier to read,
and easier
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
201 - 300 of 1172 matches
Mail list logo
