On Sat, Feb 27, 2016 at 2:44 AM, Andres Freund wrote:
> On 2016-02-02 13:12:50 +0300, Alexander Korotkov wrote:
> > On Tue, Feb 2, 2016 at 12:43 AM, Andres Freund
> wrote:
> >
> > > On 2016-02-01 13:06:57 +0300, Alexander Korotkov wrote:
> > > > On
be really chance in this situation. Users could use extension
right now. And then when after many years we finally implement the right
design, they could migrate to in-core solution. But 5-10 years of fast FTS
does matter.
> I suspect that
> a transaction manager API would end up similarly
wever, other things
are unclear.
You can try to build full-featured prototype to convince people. Despite it
would take some resources it will save more resources because it would save
us from errors.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
works.
>
> Alternately, you can just work on the individual FDW features, which
> *everyone* thinks are a good idea, and when most of them are done,
> FDW-based scaleout will be such an obvious solution that nobody will argue
> with it.
+1
Thank you, Josh. I think this is excellent summary for conversation about
FDW-based sharding.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
umbers is negligible, especially
because getting rid of this error would require way more computations. But
it worth mentioning in comments though.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Mar 3, 2016 at 7:35 PM, Tomas Vondra
wrote:
> On 03/03/2016 12:53 PM, Alexander Korotkov wrote:
>
>> I've assigned to review this patch.
>>
>> I've checked version estimate-num-groups-v2.txt by Mark Dilger.
>> It applies to head cleanly, passes
e that Mark means geometrical average, i.e. sqrt((small number) *
(huge number)).
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ve which type. Readability of this large table will be also improved.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, Mar 4, 2016 at 4:20 PM, Amit Kapila wrote:
> On Fri, Mar 4, 2016 at 4:01 PM, Alexander Korotkov
> wrote:
>
>> On Fri, Mar 4, 2016 at 7:05 AM, Amit Kapila
>> wrote:
>>
>>> > I think the wait event types should be documented - and the wait
>
ther ref pages, with a normal options list.
>
Patch applies cleanly on head, documentation compiles with no problem.
pg_resetxlog page definitely looks much better than it was before.
I don't see any problems or issues with this patch.
So, I mark it "Ready for committer".
--
t; can toggle these behaviors.
>
Would it have any usage if we make PG_SYSLOG_LIMIT configurable (-1 for
disable) instead of introducing boolean?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
plan only from explicit Sort path? Thus,
MergeJoin path would add explicit children Sort paths. That would be more
unified way.
I ask about this from point of view of my "Partial Sort" patch. The absence
of implicit sorts would help to make this patch more simple and clean.
-
On Wed, Mar 9, 2016 at 5:47 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > I have a question about Sort path. AFAICS this question wasn't mentioned
> in
> > the upthread discussion.
> > We're producing Sort plans in two ways: from explicit Sort paths
s that confidence
interval should be between lower and upper values.
Since confidence intervals for master and patched versions are overlapping
we can't conclude that expected TPS numbers are different.
Dilip, could you do more runs? 10, for example. Using such statistics we
would be able to conclude something.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
.postgresql.org/message-id/ca+tgmobyf2vchghvoks7yrxa2wde+wmmrmxyughvx_w-0wx...@mail.gmail.com
5.
http://www.enterprisedb.com/products-services-training/products/postgres-plus-advanced-server?quicktabs_advanceservertab=3#quicktabs-advanceservertab
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sat, Mar 12, 2016 at 2:45 AM, Andres Freund wrote:
> On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote:
> > Idea of individual time measurement of every wait event met criticism
> > because it might have high overhead [1].
>
> Right. And that's actually one
amine
this path more carefully next week.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
partial-sort-basic-7.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
On Fri, Mar 11, 2016 at 7:08 AM, Dilip Kumar wrote:
>
> On Thu, Mar 10, 2016 at 8:26 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> I don't think we can rely on median that much if we have only 3 runs.
>> For 3 runs we can only appl
enough for testing of GUC controlled, off by default features.
Then we can turn our conversation from theoretical thoughts to particular
benchmarks which would be objective and convincing to everybody.
Otherwise, let's just add these features to the list of unwanted
functionality and close this question.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
.7.
Links.
[1] http://www.postgrespro.com/blog/pgsql/pg_pathman
[2] http://akorotkov.github.io/blog/2016/03/04/pg_pathman-beta-release/
[3]
http://akorotkov.github.io/blog/2016/03/14/pg_pathman-condition-processing/
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
t; > MergeAppend when possible);
> > Optimization of hash join when both tables are patitioned by join key.
> >
> > I'd like to validate that this development plan doesn't overlaps with
> your
> > plans. If out plans are not overlapping then le
On Sat, Mar 19, 2016 at 3:22 PM, Dilip Kumar wrote:
>
> On Mon, Mar 14, 2016 at 3:09 AM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> I've drawn graphs for these measurements. The variation doesn't look
>> random here. TPS is going higher
= OBJECT_FUNCTION;
> + n->objname = $7->funcname;
> + n->objargs = $7->funcargs;
> + n->deptype = 'x';
> $$ = (Node *)n;
> }
by introducing separate rule extension_depen
ut to work very well even when
> the
> * number of distinct values is small.
> */
>
+1
Thank you for work on this patch. The formula you propose and explanation
look great!
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
;
'york' ) )
(1 row)
select rewrite( ARRAY['moscow', keyword, sample] ) from test_tsquery;
--- 461,469
(1 row)
select rewrite('bar & new & qq & foo & york', 'select keyword, sample
from test_tsquery'::text );
! rewrite
!
-
! ( '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
{ $$ = 'e'; }
;
...
| ALTER EXTENSION name add_drop extension_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
some more
> 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
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 efforts on
it.
ACLs using <> funcs and using IS DISTINCT for other
objects? Is it intentional? Assuming 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
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
> wrote:
>
>> Probably a better URL to give is
>> http://www.adellera.it/investigations/distinct_balls/ which has a li
On Tue, Mar 22, 2016 at 11:53 PM, Alvaro Herrera
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 started reading the complete
>
Now, 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 Pro
t; Everybody depends on it, all the time, for everything. And despite
> new tools like amcheck, it's not a particularly easy thing to debug.
>
It's all true. But:
1) It's a great feature many users dream about.
2) Patch is not very big.
3) Patch doesn't introduce si
On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera
wrote:
> .. Oh crap. I just noticed I forgot to update a comment in pg_dump's
> getAccessMethods. And we're missing psql tab-complete support for the
> new commands.
Attached patches fix both these issues.
--
Alexande
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
> wrote:
>
>>
>> On Tue, Mar 22, 2016 at 12:31 PM, Dilip Kumar
>> wrote:
>>
>>> ! pg_atomic_write_u32(&
t;
>
> 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
> feedba
Hi, Dilip!
On Fri, Mar 25, 2016 at 8:32 PM, Dilip Kumar 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 nice* to fit it into 9.
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 p
On Sun, Mar 27, 2016 at 3:10 PM, Andres Freund 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 much for testing!
>
t;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
riableCache->nextXid. 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-hacker
gt;
>>
> 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 pla
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 wrote:
>
>> On 2016-03-27 12:38:25 +0300, Alexander Korotkov wrote:
>> > On Sat, Mar 26, 2016 at 1:26 AM, Alexander Korotkov <
On Tue, Mar 29, 2016 at 6:20 PM, David Steele 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>
>>> wrote:
>>>
>
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
neric_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
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
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 wrote:
>
>> I incorporated your changes and did some additional refinements on top of
>>> them
>>> still.
>>>
&
ngs, 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
t;
> >> * cost_sort() needs way way more comments. Doesn't even mention
> >> indexes. Not worth commenting further on until I know what it's
> >> *supposed* to do, though.
> >
> >
> > I've added some comments.
>
> Looking at cos
Hi, Tomas!
On Sat, Jan 23, 2016 at 3:07 PM, Tomas Vondra
wrote:
> On 10/20/2015 01:17 PM, Alexander Korotkov wrote:
>
>> On Fri, Oct 16, 2015 at 7:11 PM, Alexander Korotkov
>> mailto:aekorot...@gmail.com>> wrote:
>>
>> On Sun, Jun 7, 2015 at 11:01
x27;m sorry for huge
delay I made. I'm going to get back to this soon.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ll, but the other two have seen a
> bit of discussion and evolution. Is anyone doing any more reviewing?
I'd like to add another one: fixed tranche id for each SLRU.
And I'm going to make review over others.
--
Alexander Korotkov
Postgres Professional: http://www.postg
body.
+1 for dropping old API
I don't think it's useful to have LWLocks without having shared memory.
There is another thing I'd like extensions to be able to do. It would be
nice if extensions could use dynamic shared memory instead of static. Then
extensions could use shared memory without being in
shared_preload_libraries. But if extension register DSM, then there is no
way to tell other backends to use it for that extension. Also DSM would be
deallocated when all backends detached from it. This it out of scope for
this patch though.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
t, I have updated the docs to reflect the changes related
> to new API's.
>
> Fe things to Note -
> Some change is needed in LWLockCounter[1] if this goes after 2
> other patches (separate tranche for PGProcs and separate tranche
> for ReplicationSlots). Also, LWLockAssig
ests.
I also did small testing of replication slots in order to check that it
works correctly.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
YPE INDEX or something
> like that.
>
Ok! Let's nail down the syntax and I can integrate it into my createam
patch.
I would prefer "CREATE {INDEX | SEQUENCE | ... } ACCESS METHOD name HANDLER
handler;", but I don't insist.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
tures.
Should we think more about naming? Does two kinds of generic records
confuse people?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
532052 552148
> 128412755 478826
> 256 346701 372057
>
Could you please re-run these tests few times?
Just to be sure it's a reproducible regression with s=300 and not a
statistical error.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
t; Seq Scan on t1 (cost=0.00..15406.00 rows=100
width=12) (actual time=0.012..78.828 rows=100
Planning time: 0.132 ms
Execution time: 301.308 ms
(12 rows)
In this example LIMIT pushdown makes query 5 times faster. It would be very
nice if optimizer make this automatically.
--
Alexander
On Sat, Jan 30, 2016 at 10:58 AM, Amit Kapila
wrote:
> On Fri, Jan 29, 2016 at 6:47 PM, Robert Haas
> wrote:
> >
> > On Fri, Jan 29, 2016 at 6:59 AM, Alexander Korotkov
> > wrote:
> > > On Thu, Jan 21, 2016 at 12:37 AM, Alvaro Herrera <
> alvhe...@2ndquad
393151
> 64387339496830
> 128306412350610
>
> Shared Buffer= 512MB
> max_connections=150
> Scale Factor=300
>
> ./pgbench -j$ -c$ -T300 -M prepared -S postgres
>
> ClientBasePatch
> 117169 16454
> 8108547105559
On Sat, Jan 30, 2016 at 11:58 AM, Simon Riggs wrote:
> On 29 January 2016 at 21:11, Alexander Korotkov > wrote:
>
>> Hi, Petr!
>>
>> On Sat, Jan 23, 2016 at 1:22 AM, Petr Jelinek
>> wrote:
>>
>>> here is updated version of this patch, call
On Mon, Feb 1, 2016 at 10:26 AM, Amit Kapila
wrote:
> On Sat, Jan 30, 2016 at 2:15 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
> >
> > On Sat, Jan 30, 2016 at 10:58 AM, Amit Kapila
> wrote:
> >>
> >> On Fri, Jan 29, 2016 at 6:47 P
On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Mon, Feb 1, 2016 at 7:05 AM, Dilip Kumar wrote:
>
>>
>> On Sun, Jan 31, 2016 at 11:44 AM, Dilip Kumar
>> wrote:
>>
>>> By looking at the results with scale f
not enough for
some tranches. For instance, number of buffers could be easily more than
2^16. However, we could expose at least lower 16 bits. It would be at least
something. Using this information user at least can make a conclusion like
"It MIGHT be a high concurrency for single buffer content. Other way it is
coincidence that a lot of different buffers have the same 16 lower bits.".
Any thoughts?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
9.5.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix-knn-gist-ordering-type.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Tue, Feb 2, 2016 at 12:43 AM, Andres Freund wrote:
> On 2016-02-01 13:06:57 +0300, Alexander Korotkov wrote:
> > On Mon, Feb 1, 2016 at 11:34 AM, Alexander Korotkov <
> > a.korot...@postgrespro.ru> wrote:
> > >> ClientBasePatch
> > >> 1
On Mon, Feb 1, 2016 at 7:31 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> KNN GiST detects which type it should return by returning type of ordering
> operator.
> But it appears that type of sk_func is detected after it was replaced with
> distance function. That
On Tue, Feb 2, 2016 at 2:54 PM, Robert Haas wrote:
> On Mon, Feb 1, 2016 at 3:47 AM, Alexander Korotkov
> wrote:
> > OK. This one looks good for me too.
>
> All right, I pushed both this and the other one as a single commit,
> since they were so closely related and the
On Sat, Jan 30, 2016 at 3:37 PM, Petr Jelinek wrote:
> On 29 January 2016 at 23:59, Robert Haas wrote:
> > On Fri, Jan 29, 2016 at 5:24 PM, Tom Lane wrote:
> >> Alexander Korotkov writes:
> >>> On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera <
> a
reated wiki page for GSoC 2016. It contains unimplemented ideas from
2015 page.
Now, GSoC accepting proposals from organizations. Typically, we have call
for mentors in hackers mailing list in this period.
Thom, do we apply this year?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
gt;
I have nothing against particular FDW advances. However, it's unclear for
me that FDW should be the only sharding approach.
It's unproven that FDW can do work that Postgres XC/XL does. With FDW we
can have some low-hanging fruits. That's good.
But it's unclear we can have
oesn't pick it. Assuming that
in new session planner picks this index, it seems to be bug for me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
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 case, each
storage would have own optimized executor nodes.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
cause 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 Pos
On Fri, Aug 19, 2016 at 4:46 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > originally this idea was proposed by Andres Freund while experimenting
> with
> > lockfree Pin/UnpinBuffer [1].
> > The patch is attached as well as results of pgbench -S on 72-cores
&g
On Fri, Aug 19, 2016 at 3:19 PM, Amit Kapila
wrote:
> On Fri, Aug 19, 2016 at 11:42 AM, Alexander Korotkov
> wrote:
> > Hackers,
> >
> > originally this idea was proposed by Andres Freund while experimenting
> with
> > lockfree Pin/UnpinBuffer [1].
> > T
SENDER_WRITE_DATA:
> res = "WalSenderWriteData";
> break;
> default:
> res = "???";
> }
> return res;
> }
Would it be better to use an array here?
typedef enum EventIdentifier
> {
EventIdentifier seems too general name for me, isn't it? Could
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)
&
orker at separate index seems to be fair enough for
majority of cases.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
tached 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
On Fri, Apr 8, 2016 at 10:09 PM, Peter Geoghegan wrote:
> On Wed, Mar 30, 2016 at 8:02 AM, Alexander Korotkov
> wrote:
> > Hmm... I'm not completely agree with that. In typical usage partial sort
> > should definitely use quicksort. However, fallback to other sort
>
On Tue, Oct 3, 2017 at 2:52 PM, Robert Haas wrote:
> On Mon, Oct 2, 2017 at 12:37 PM, Alexander Korotkov
> wrote:
> > I've applied patch on top of c12d570f and rerun the same benchmarks.
> > CSV-file with results is attached. There is no dramatical changes.
> Ther
On Tue, Oct 3, 2017 at 5:55 PM, Robert Haas wrote:
> On Mon, Oct 2, 2017 at 8:07 PM, Alexander Korotkov
> wrote:
> > +1,
> > I see 3 options there:
> > 1) Drop high-order bit, as you proposed.
> > 2) Allow negative queryIds.
> > 3) Implement unsigned 64-t
egradation in this case. That's very significant
degradation, but I wouldn't day that "performance completely tank".
Any thoughts? Should we consider TOASTing ACL entries or should we give up
with this?
Links:
1. https://www.commandprompt.com/blog/grant_schema_usage_
to
On Tue, Oct 3, 2017 at 9:19 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > This topic was already discussed (at least one time) in 2011. See [1]
> for
> > details. I'd like to raise that again.
>
> I'm a bit worried about adding a toast table to pg_clas
ectly. We
could try to re-implement similar functionality which fits pageinspect
approach better. In particular, we can implement some low-level functions
whose show detailed information at page level. And on top of them we can
implement analogues of gevel functions in SQL or PL/pgSQL. Is it feasible?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
enerate_series(1,1) i) to 'script.sql'
\i script.sql
Then user u1 can login successfully.
$ psql temp -U u1
psql (11devel)
Type "help" for help.
u10000@temp=#
Thus, in this simple case database CONNECT privilege works with out-of-line
ACL for me.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
SIReadLock on tuple is necessary.
However, ISTM that we could place SIReadLock on tuple after Before Row
Trigger and only in the case when trigger has cancelled an update.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Oct 5, 2017 at 9:48 PM, Shubham Barai
wrote:
> On 3 October 2017 at 00:32, Alexander Korotkov
> wrote:
>
>> On Mon, Oct 2, 2017 at 9:11 PM, Andrew Borodin
>> wrote:
>>
>>> On Mon, Oct 2, 2017 at 8:00 PM, Alexander Korotkov
>>> wrote:
>&
On Wed, Sep 27, 2017 at 7:51 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> I took a look on this patch. I've following notes for now.
>
> tuple_insert_hook tuple_insert; /* heap_insert */
>> tuple_update_hook tuple_update; /* heap_update */
>>
On Mon, Oct 9, 2017 at 5:32 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > For me, it's crucial point that pluggable storages should be able to have
> > different MVCC implementation, and correspondingly have full control over
> > its interactions with indexes.
On Wed, Oct 11, 2017 at 11:08 PM, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 10:22 AM, Alexander Korotkov
> wrote:
> > For me, it's crucial point that pluggable storages should be able to have
> > different MVCC implementation, and correspondingly have full control ov
it wouldn't have significant performance benefit, then there is no
reason to do something further...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
of indexes.
Wherein these new index entries may have either same or new TIDs.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
(and document it),
but don't tolerate wrong features. For instance, we may have some pluggable
storage which doesn't support transactions at all (and that should be
documented for sure), but we shouldn't have pluggable storage which
transaction support is wrong.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Wed, Sep 6, 2017 at 4:42 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> We're currently blocking writing queries on standby if even they are
> modifying contents of foreign tables. But do we have serious reasons for
> that?
> Keeping in the mind FDW-shar
367 | (31018, 367),(30946, 333)
> 377 | (11399, 377),(11360, 294)
> (15 rows)
>
>
> Seems like a bug somewhere in gist_cube_ops, I guess?
>
+1,
that definitely looks like a bug. Thank you for reporting!
I'll take a look on it in couple days.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
"
>
> -
> /*
> * Maximum size of a NOTIFY payload, including terminating NULL. This
> * must be kept small enough so that a notification message fits on one
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
1 - 100 of 1051 matches
Mail list logo
