n code. For safety, this patch replaces psql() with
safe_psql() in other places too.
I think this should be backpatched to 9.6 as bugfix.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix-bloom-wal-check.patch
Description: Binary data
--
Sent
> {
> LogAccessExclusiveLockPrepare();
> - log_lock = true;
> +// log_lock = true;
> }
>
> /*
Perhaps, it's certainly bad idea to disable replaying AccessExclusiveLock
*every time*, we should skip taking AccessExclusiveLock only while writing
XLOG_SMGR_TRUNCATE record. Besides that, this code violates out coding
style.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
, the updated
patch is attached.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected/postgres_fdw.out
index c19b3318c7..5f5f65d60c 100644
--- a/contrib
Hi, Adrien!
On Mon, Sep 4, 2017 at 3:57 PM, Adrien Nayrat <adrien.nay...@dalibo.com>
wrote:
> On 08/30/2017 02:26 PM, Alexander Korotkov wrote:
> I reviewed this patch. It works as expected but I have few remarks :
>
Thank you for reviewing my patch!.
> * There i
cumentation
for previous releases would be good too.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Apr 6, 2017 at 5:38 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Apr 6, 2017 at 5:37 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Thu, Apr 6, 2017 at 2:16 AM, Andres Freund <and...@anarazel.de> wrote:
&g
On Thu, Jun 1, 2017 at 4:10 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Wed, May 31, 2017 at 7:18 PM, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
>
>> On Wed, May 31, 2017 at 6:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
&
h.
I hope you find these points helpful.
[1]
https://www.postgresql.org/message-id/flat/1d23ad41-a9d9-1d1e-1d79-83b002d6f776%40postgrespro.ru#1d23ad41-a9d9-1d1e-1d79-83b002d6f...@postgrespro.ru
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Here is a new version of the patch, rebased to 749c7c41 and with some
cosmetic changes.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index d77c2a70e4
pointer, and the
calling code would look cleaner -- just one line. This is a matter of
taste though.
* The nearby functions use snake_case, so it should be
rebuild_concat_cache too.
Overall the patch looks good to me.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
it would have to process less pages, and the bitmap
would be less lossy.
I didn't benchmark the index scan per se with the 0.9 fill factor, but
the reduction of lossy pages was significant.
Regards,
Alexander Kuzmenkov
[1]
https://www.postgresql.org/message-id/flat/251401bb-6f53-b957-4128-578
|Hello everyone,
I made a new patch according to the previous comments. It is simpler
now, only adding a few checks to the bitmap heap scan node. When the
target list for the bitmap heap scan is empty, and there is no filter,
and the bitmap page generated by the index scan is exact, and the
on error it would be more natural to give
up with current transaction and continue with next one.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Aug 14, 2017 at 2:09 PM, Mark Rofail <markm.rof...@gmail.com> wrote:
> On Tue, Aug 8, 2017 at 3:24 PM, Alexander Korotkov <aekorot...@gmail.com>
> wrote:
>
>> On Tue, Aug 8, 2017 at 4:12 PM, Mark Rofail <markm.rof...@gmail.com>
>> wrote:
>>
standard over the code. Ildus, please check you patches carefully before
publishing.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
nevitable, but it's a long distance feature.
Thus, this optimization could make us a good serve before we would have CSN.
Do you expect there are cases when this patch causes slowdown? What about
case when we scan each xip array only once (not sure how to simulate that
using pgbench)?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
tradeoff between performance of old format reading and amount of extra
code needed. Once we will have benchmarks we can consider whether this is
the solution we would like to buy.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Aug 8, 2017 at 4:12 PM, Mark Rofail <markm.rof...@gmail.com> wrote:
> On Tue, Aug 8, 2017 at 2:25 PM, Alexander Korotkov <aekorot...@gmail.com>
> wrote:
>>
>> Do we already assume that default btree opclass for array element type
>> matches PK opcla
CT count(*) () z)
>
> I understand there might be some syntax errors but this is just a proof of
> concept.
>
GROUP BY would also use default btree/hash opclass for element type. It
doesn't differ from DISTINCT from that point.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
it with the group clog update patch.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jul 27, 2017 at 3:07 PM, Mark Rofail <markm.rof...@gmail.com> wrote:
> On Thu, Jul 27, 2017 at 12:54 PM, Alexander Korotkov <aekorot...@gmail.com
> > wrote:
>>
>> How many rows of FK table were referencing the PK table row you're
>> updating/deleting.
00 rows,
> 10,000 rows,
> 100,000 rows and
> 1,000,000 rows
>
How many rows of FK table were referencing the PK table row you're
updating/deleting.
I wonder how may RI trigger work so fast if it has to do some job besides
index search with no results?
I think we should also vary the
mplicit casts. Array FK should not necessary have the same type
restrictions. Also, we don't necessary need to make those restrictions as
soft as possible during this GSoC project.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
hole index.
pageinspect is written in another manner: it gives you functionality to
analyze individual pages, tuples and so on.
Thus, we probably shouldn't try to move gevel functions to pageinspect "as
is". They should be rewritten in more granular manner as well as other
pageinspact
That's not actually a problem as I am reusing an older v4 from Heikki
now for the future, but I wanted to let you know about that first.
Thank you, I'll look into that.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql
4[] @>> int8, int4[] @>> int4, int4[] @>> int2, int4[] @>> numeric. You
tried to add multiple pg_amop rows for single operator and consequently get
unique index violation.
Alvaro, do you think we need to define all these operators? I'm not sure.
If even we need it, I think we
On Mon, Jul 17, 2017 at 7:51 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Mon, Jul 17, 2017 at 3:22 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > I think that "retail index tuple deletion" is the feature which could
> give
> >
e, it would be possible
to use indirect indexes when primary key is not 6-bytes, if index AM
supports arbitrary payload.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sat, Jul 15, 2017 at 5:14 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Jun 22, 2017 at 9:30 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > If #1 is only about changing tuple and page formats, then could be much
> > simpler than the pat
t <= SimpleLruShmemSize(nslots,
> nlsns)) at the end of SimpleLruInit()
Good point. Please, find it in attached patch.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix-slru-lwlock-shmem-double-allocation-2.patch
Description: Binary
cks = (LWLockPadded *) ShmemAlloc(sizeof(LWLockPadded) *
nslots);
Attached patch fixes that by removing extra ShmemAlloc for SLRU.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
fix-slru-lwlock-shmem-double-allocation.patch
Description: Bin
On Sun, Jul 9, 2017 at 1:11 PM, Mark Rofail <markm.rof...@gmail.com> wrote:
> On Sun, Jul 9, 2017 at 2:38 AM, Alexander Korotkov <aekorot...@gmail.com>
> wrote:
>
>> Could you, please, specify idea of what you're implementing in more
>> detail?
>>
>
and execute it. As you can see, this is done in many other
places of backend code.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
d line option. But I'm +1 to add this option.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Jun 27, 2017 at 4:19 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Thu, Jun 22, 2017 at 5:46 PM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > On Tue, Jun 13, 2017 at 4:50 AM, Haribabu Kommi <
> kommi.harib...@gmail.com>
> > wro
On Tue, Jun 27, 2017 at 4:08 PM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> On Thu, Jun 22, 2017 at 8:00 PM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > On Wed, Jun 21, 2017 at 10:47 PM, Robert Haas <robertmh...@gmail.com>
> wrote:
> >
On Mon, Jun 26, 2017 at 10:55 PM, Tomas Vondra <tomas.von...@2ndquadrant.com
> wrote:
> On 06/26/2017 05:18 PM, Alexander Korotkov wrote:
>
>> I see that design question for PostgreSQL pluggable storages is very hard.
>>
>
> IMHO it's mostly expected to be
ass null inputs to your
function if its declared as strict. See evaluate_function().
Also, during query planning it's checked that all polymorphic are
consistent between each other. See
https://www.postgresql.org/docs/devel/static/extend-type-system.html#extend-types-polymorphic
and check_gene
.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Jun 22, 2017 at 5:27 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Jun 22, 2017 at 8:32 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > On Thu, Jun 22, 2017 at 4:01 AM, Michael Paquier <
> michael.paqu...@gmail.com>
> &g
of
tuples *in particular page*. There is no need to redefine high-level logic
for scanning heap, doing updates and so on...
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
>
> #define TRUEtrue
> #define FALSE false
>
+1
I don't know any policy about where to use TRUE and FALSE over true and
false.
# NIL seems causing similar mess.
>
NIL is used for lists, while NULL is used for other pointers.
That may cause redundant, but at least there is c
n could be useful for users. Then while saying that #1 is useful for
users, it would be nice to keep in mind particular storage AMs which can be
implemented using #1.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
is untouched in the patchset and it is not
mentioned in this discussion.
Do you plan to override low-level function like heap_page_prune(),
lazy_vacuum_page() etc., but preserve high-level logic of vacuum?
Or do you plan to let pluggable storage implement its own high-level vacuum
algorithm?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
, and that leads to duplication. Unfortunately, I didn't have
time yet to investigate this further.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
csn-5.patch.gz
Description: application/gzip
--
Sent via pgsql-hackers mailing list (pgsql
?
>
>
As I know, it's implicitly checked during query analyze stage. You don't
have to implement your own check inside function implementation.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ordingly.
> And to do that, you need to hold a lock on the page. If you don't move any
> tuples around at the same time, but just update the XID fields, and
> exclusive lock on the page is enough, i.e. you don't need to take a
> super-exclusive or vacuum lock. In any case, it happens so infrequently
> that it should not become a serious burden.
Yes, exclusive lock seems to be enough for single page freeze.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
h
> to appear soon, I think.
>
Right. I'm now working on splitting my large patch for 64-bit xids into
patchset.
I'm planning to post patchset in the beginning of next week.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
to change this behavior somehow? First look into pg_xlog and
only if file is missing or "corrupted" call restore_command.
Regards,
---
Alexander Kukushkin
On Wed, May 31, 2017 at 7:18 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Wed, May 31, 2017 at 6:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
>> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
>> > I've discovered that P
On Wed, May 31, 2017 at 6:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> > I've discovered that PostgreSQL is able to run following kind of queries
> in
> > order to change statistic-gathering target for an i
ex_name ALTER EXPRESSION 0 SET STATISTICS stat_target; --
Refer expression by its number
ALTER INDEX index_name ALTER EXPRESSION (x + y) SET STATISTICS stat_target;
-- Refer expression by its definition
1.
https://www.postgresql.org/message-id/flat/20150716143149.GO2301%40postgresql.org
--
Alexander
Alvaro Herrera writes:
>> I can reproduce a segmentation fault when creating a BRIN concurrently
>> with set pages_per_range and autosummarize.
>
> Pushed fix just now. Please give it a try. Thanks for testing and
> reporting,
Thank you for fixing, works for me.
Reg
nd regards,
Alexander Sosna
2017-05-30 16:19:27.374 CEST [22160] postgres@postgres DEBUG: StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
2017-05-30 16:19:27.374 CEST [22160] postgres@postgres STATEMENT: CREATE INDEX CONCURRENTLY brin_test_ti
pclass. Those
procedures are defined in src/backend/access/gin/ginarrayproc.c.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 16.05.2017 18:57, Robert Haas wrote:
Interesting. I suggest adding this to the next CommitFest.
Thank you, added: https://commitfest.postgresql.org/14/1141/
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers
=50014145 loops=1)
Sort Key: t5.a
Sort Method: quicksort Memory: 8541kB
-> Seq Scan on t5 (cost=0.00..1443.00 rows=10 width=4)
(actual time=0.013..8.570 rows=10 loops=1)
Planning time: 2.368 ms
Execution time: 10530.356 ms
(10 rows)
--
Alexander Kuzmenkov
P
sed practice to prepend number to the patch name
while dealing with patch set.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
I didn't mean Teodor has renamed it.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
-> Index Only Scan using t3i2 on t3 (cost=0.42..4358.37
rows=70530 width=66) (actual time=0.015..10.484 rows=70094 loops=1)
Heap Fetches: 0
Planning time: 2.571 ms
Execution time: 18.778 ms
(14 rows)
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Apr 27, 2017 at 5:06 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Apr 26, 2017 at 11:39 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > But I'd like to make incremental sort not slower than quicksort in case
> of
> > presort
On Wed, Apr 26, 2017 at 8:20 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Wed, Apr 26, 2017 at 10:10 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > OK, I get it. Our qsort is so fast not only on 100% presorted case.
> > However, that doesn't
On Wed, Apr 26, 2017 at 7:56 PM, Peter Geoghegan <p...@bowt.ie> wrote:
> On Wed, Apr 26, 2017 at 8:39 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > That appears to be wrong. I intended to make cost_sort prefer plain sort
> > over incremen
ative partitioning
because it still uses very inefficient constraint exclusion mechanism.
Thus, issues you are writing about would become visible on declarative
partitioning only when constraint exclusion would be replaced with
something more efficient.
Long story short, could you reproduce this is
On 12.04.2017 12:29, Alexander Korotkov wrote:
That's a cool feature for FTS users! Please, register this patch to
the next commitfest.
I've added this to the 2017-07 commitfest:
https://commitfest.postgresql.org/14/1117/
Also, what is planning overhead of this patch? That's worth
s_tenthous (cost=0.00..6.68
rows=319 width=0)
Index Cond: (thousand < 31)
(6 rows)
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On 12.04.2017 15:04, Tom Lane wrote:
Andrew Gierth <and...@tao11.riddles.org.uk> writes:
"Alexander" == Alexander Kuzmenkov <a.kuzmen...@postgrespro.ru> writes:
Alexander> Structurally, the patch consists of two major parts: a
Alexander> specialized exec
On Wed, Apr 12, 2017 at 12:40 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Tue, Apr 11, 2017 at 8:24 PM, Alexander Kuzmenkov <
> a.kuzmen...@postgrespro.ru> wrote:
>
>> I would like to propose a patch that speeds up the queries of the form
>&
y own, but it uses replace_nestloop_params() (again, static),
> and the problem goes further and further.
>
As I understand, making build_path_tlist a non-static function would solve
the problem.
Tom, do you think it's possible?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Apr 11, 2017 at 8:24 PM, Alexander Kuzmenkov <
a.kuzmen...@postgrespro.ru> wrote:
> I would like to propose a patch that speeds up the queries of the form
> 'select
> count(*) ... where ...', where the restriction clauses can be satisfied
> by some
> indexes. At the
mplemented during the PostgreSQL 11 release cycle.
* For some indexes, the bitmap index scan will always require rechecking
all
the tuples. Bitmap count plans should not be used in such cases. For
now, this
check is not implemented.
I would be glad to hear your comments on this patch.
Regards,
On Tue, Apr 11, 2017 at 5:46 PM, Jeff Davis <pg...@j-davis.com> wrote:
> On Tue, Apr 11, 2017 at 2:17 AM, Alexander Korotkov
> <a.korot...@postgrespro.ru> wrote:
> > FYI, I've implemented this algorithm for pgsphere. See following branch.
> > https://gith
//github.com/akorotkov/pgsphere/tree/crossmatch_cnode
You also can find some experimental evaluation here:
http://www.adass2016.inaf.it/images/presentations/10_Korotkov.pdf
Feel free to experiment with this code and/or ask any question.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Thu, Apr 6, 2017 at 5:37 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Thu, Apr 6, 2017 at 2:16 AM, Andres Freund <and...@anarazel.de> wrote:
>
>> On 2017-04-03 11:56:13 -0700, Andres Freund wrote:
>> > Have you done x86 benchmarking?
>&
+ }
> > > + pg_unreachable();
> > > +}
> > > +#endif
> >
> > Have you done x86 benchmarking?
>
> I think unless such benchmarking is done in the next 24h we need to move
> this patch to the next CF...
>
Thank you for your comments.
I didn't x86 benchmarking. I even didn't manage to reproduce previous
results on Power8.
Presumably, it's because previous benchmarks were done on bare metal, while
now I have to some kind of virtual machine on IBM E880 where I can't
reproduce any win of Power8 LWLock optimization. But probably there is
another reason.
Thus, I'm moving this patch to the next CF.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
do not hit a broken line.
I think that situation when backend is directly reading file during COPY is
not typical. More typical case is \copy psql command. In that case "COPY
... FROM stdin;" is actually executed while psql is streaming the data.
How can we apply parallel COPY in th
ve that “<@( is
> contained by)” can be used in this scope.
What exactly you're going to do in this item? Check that GIN index over
array support given operator, do the performance benchmark or something
else?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
;
I'd love to see a comment from Andres Freund who is leading executor
performance improvements.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Apr 3, 2017 at 9:58 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2017-03-25 19:35:35 +0300, Alexander Korotkov wrote:
> > On Wed, Mar 22, 2017 at 12:23 AM, David Steele <da...@pgmasters.net>
> wrote:
> >
> > > Hi Alexander
> > >
&g
On Tue, Apr 4, 2017 at 12:09 AM, Andres Freund <and...@anarazel.de> wrote:
> On 2017-04-04 00:04:09 +0300, Alexander Korotkov wrote:
> > > >Thank you!
> > > >I already sent version of patch after David's reminder.
> > > >Please find rebased patch
On Mon, Apr 3, 2017 at 10:05 PM, Andres Freund <and...@anarazel.de> wrote:
> On April 3, 2017 12:03:56 PM PDT, Alexander Korotkov <
> a.korot...@postgrespro.ru> wrote:
> >On Mon, Apr 3, 2017 at 9:34 PM, Andres Freund <and...@anarazel.de>
> >wrote:
> >
&g
On Sun, Mar 26, 2017 at 12:29 AM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Sat, Mar 25, 2017 at 11:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
>> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
>> > I moved PPC impleme
On Tue, Mar 28, 2017 at 10:12 AM, Pavel Stehule <pavel.steh...@gmail.com>
wrote:
> 2017-03-27 13:59 GMT+02:00 Alexander Korotkov <a.korot...@postgrespro.ru>:
>
>> On Fri, Mar 10, 2017 at 6:06 PM, Pavel Stehule <pavel.steh...@gmail.com>
>> wrote:
>>
Hello,
Please consider committing the attached patches to remove trailing
spaces in strings in the source code.
One patch is for localizable messages, and the other is just for
consistency (less important).
--
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian
On Tue, Mar 28, 2017 at 5:27 PM, David Steele <da...@pgmasters.net> wrote:
> Hi Alexander,
>
> On 3/20/17 10:19 AM, Heikki Linnakangas wrote:
>
>> On 03/20/2017 11:33 AM, Alexander Korotkov wrote:
>>
>>> Please, find rebased patch in the a
On Thu, Aug 4, 2016 at 2:28 PM, Ildar Musin <i.mu...@postgrespro.ru> wrote:
> I was looking through the buffer manager's code and have noticed that
> function PinBuffer has an unused 'strategy' argument. It's seems that after
> refactoring made by Alexander Korotkov an
nly connections
2017-03-27 17:32:16.920 MSK [30788] LOG: started streaming WAL from
primary at 0/900 on timeline 1
done
server started
# select pg_is_in_recovery();
pg_is_in_recovery
───
t
(1 row)
Thus, I think patch is working as expected in this case.
Also,
re end of online backup"),
> errhint("Online backup started with pg_start_backup() must be ended with
> pg_stop_backup(), and all WAL up to that point must be available at
> recovery.")));
> else
> ereport(FATAL,
> (errmsg("WAL ends before consistent recovery point")));
Should we consider fixing them?
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Fri, Mar 10, 2017 at 6:06 PM, Pavel Stehule <pavel.steh...@gmail.com>
wrote:
> 2017-03-10 16:00 GMT+01:00 Alexander Korotkov <a.korot...@postgrespro.ru>:
>
>> On Fri, Mar 10, 2017 at 5:16 PM, Stephen Frost <sfr...@snowman.net>
>> wrote:
>
On Sat, Mar 18, 2017 at 12:41 AM, Pritam Baral <pri...@pritambaral.com>
wrote:
> On Friday 10 March 2017 07:59 PM, Alexander Korotkov wrote:
>
>> Hi, Pritam! > > I've assigned to review this patch. > > On Thu, Feb 23,
>> 2017 at 2:17 AM, Pritam
On Sat, Mar 25, 2017 at 11:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> > I moved PPC implementation of pg_atomic_fetch_mask_add_u32() into
> > port/atomics/arch-ppc.h. I also had to declare pg_atomic_uint32
On Sat, Mar 25, 2017 at 8:44 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> > [ lwlock-power-3.patch ]
>
> I experimented with this patch a bit. I can't offer help on testing it
> on large PPC machines, b
On Thu, Mar 16, 2017 at 8:35 PM, David Steele <da...@pgmasters.net> wrote:
> On 2/21/17 9:54 AM, Bernd Helmle wrote:
> > Am Dienstag, den 14.02.2017, 15:53 +0300 schrieb Alexander Korotkov:
> >> +1
> >> And you could try to use pg_wait_sampling
>
48354581a49c30f5757c203415aa8412d85b0f70 at April, 10. Does it mean the
> fix should be backpatched too?
I think so. This patch reverts unintentional change and can be considered
as bug fix.
BTW, sorry for unicode filename in previous letter.
Patch with normal ASCII name is attached.
--
Alexander
>
> if (BUF_STATE_GET_USAGECOUNT(buf_state) != BM_MAX_USAGE_COUNT)
>
> being prone to paranoia, I prefer the first, but I've seen both styles in
> the code so I don't know if it's worth futzing with.
>
Ok, let's be paranoic and do this same way as before. Revised patch is
attac
approaches
you're going to try, and specify them in proposal. Schedule should include
prototyping each of these approaches, then testing and benchmarking to
selecting between them, then work on bringing selected approach to
committable shape.
--
Alexander Korotkov
Postgres Professional: ht
between different sortings
quickly. For instance, after seeing tables sorted by name, user can
require them sorted by size descending, then sorted by size ascending,
etc...
Therefore, I find user-defined SQL clause to be cumbersome. Even psql
variable itself seems to be cumbersome for me.
I would propose t
name and table name.
I think sorting by schema name, object name makes sense for people, who
have objects of same name in different schemas.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Node *leftop, Oid expr_op, Oid
opfamily,
^
Could you please recheck that you published right version of patch?
Also, I noticed that patch haven't regression tests. Some mention of this
optimization in docs is also nice to have.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
196 27628 28511 3.19603301
> 256 28467 28529 0.2177960445
>
Results look good for me. Idea of committing both of patches looks
attractive.
We have pretty much acceleration for read-only case and small acceleration
for read-write case.
I'll run benchmark on 72-cores machine as well.
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
101 - 200 of 1172 matches
Mail list logo
