The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
The patch looks fine to me. Changes are clear and all functions are c
No?
I changed it. Now we always use highkey saved in xlog.
This code don't needed anymore and can be deleted. Thank you for the
notice. I will send updated patch today.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via
31.03.2017 20:57, Robert Haas:
On Fri, Mar 31, 2017 at 1:40 PM, Anastasia Lubennikova
wrote:
First of all, I want to thank you and Robert for reviewing this patch.
Your expertise in postgres subsystems is really necessary for features like
this.
I just wonder, why don't you share your tho
orm_tuple() calls.
But index_form_tuple_extended() looks like a better solution.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
e do need it. */
That is not a very informative comment.
+* NOTE It is not crutial for reliability in present,
Spelling, punctuation.
Will be fixed as well.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailin
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi, I've tried to review this patch, but it seems that I miss something
esse
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
The patch looks good to me.
It applies clearly, passes all the te
Patch rebased to the current master is in attachments.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
commit 497d52b713dd8f926b465ddf22f21db7229b12e3
Author: Anastasia
Date: Tue Mar 21 12:58:13 2017 +0300
include_columns_10.0_v4
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
As I can see, this bugfix was already discussed and reviewed.
All
t"
"/home/anastasia/newprojects/original_repo/postgres/contrib/btree_gin/results/enum.out"
>
"/home/anastasia/newprojects/original_repo/postgres/contrib/btree_gin/results/enum.out.diff"
Please, add regression test for btree_gin, and this patch can be
considered "Read
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
As I see, this bugfix works as expected and the patch is smal
As far as I understand, in this thread were discussed two bugs of
pg_stop_backup().
Thanks to the clear descriptions above, I easily reproduced both of them.
BUG#1:
Server crashes on assertion on call of pg_stop_backup(false) after interrupted
call of pg_stop_backup(false).
TRAP: FailedAssertion
13.03.2017 11:53, Artur Zakirov:
On 15.02.2017 20:54, Anastasia Lubennikova wrote:
Done.
I have gotten the error that AlterUserMappingStmt doesn't have
if_not_exists (in Russian):
gram.y: В функции «base_yyparse»:
gram.y:4918:7: ошибка: «AlterUserMappingStmt {aka s
13.02.2017 19:34, Andrew Dunstan:
On 01/13/2017 08:36 AM, Anastasia Lubennikova wrote:
I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER
MAPPING statements
for one of our customers.
I think other users can also find it useful for scripting and
automated tasks.
The patches
dback.
If you find it useful, I can also add support of json and other types,
such as smallint and bigint.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/utils/adt/jsonb.c b/src/backend/utils/adt/jsonb.c
index b
patch. Hope to see it in 10.0.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
soc/timeline
--
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
27.12.2016 17:33, Amit Kapila:
On Fri, Dec 23, 2016 at 6:42 PM, Anastasia Lubennikova
wrote:
22.12.2016 07:19, Amit Kapila:
On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested
I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER
MAPPING statements
for one of our customers.
I think other users can also find it useful for scripting and automated
tasks.
The patches themselves are small and simple. Documentation is updated as
well.
--
Anastasia
27.12.2016 20:14, Claudio Freire:
On Tue, Dec 27, 2016 at 10:41 AM, Anastasia Lubennikova
wrote:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x006941e7 in lazy_vacuum_heap (onerel=0x1ec2360,
vacrelstats=0x1ef6e00) at vacuumlazy.c:1417
1417tblk
27.12.2016 16:54, Alvaro Herrera:
Anastasia Lubennikova wrote:
I ran configure using following set of flags:
./configure --enable-tap-tests --enable-cassert --enable-debug
--enable-depend CFLAGS="-O0 -g3 -fno-omit-frame-pointer"
And then ran make check. Here is the stacktrace
23.12.2016 22:54, Claudio Freire:
On Fri, Dec 23, 2016 at 1:39 PM, Anastasia Lubennikova
wrote:
I found the reason. I configure postgres with CFLAGS="-O0" and it causes
Segfault on initdb.
It works fine and passes tests with default configure flags, but I'm pretty
sure tha
22.12.2016 21:18, Claudio Freire:
On Thu, Dec 22, 2016 at 12:22 PM, Claudio Freire wrote:
On Thu, Dec 22, 2016 at 12:15 PM, Anastasia Lubennikova
wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature
22.12.2016 07:19, Amit Kapila:
On Wed, Dec 21, 2016 at 8:46 PM, Anastasia Lubennikova
wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi,
I haven't read through the thread yet, just tried to apply the patch
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Hi, thank you for the patch.
Results are very promising. Do y
requires a PG_CONTROL_VERSION bump.
But as far as I see, we never use this data.
Could you please explain, why don't we use information from control file
in StartapXlog()?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent vi
PR06MB504CD8FE8AA30D4B7C958AAE39E0%40AMSPR06MB504.eurprd06.prod.outlook.com
--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Could you please add the patches to commitfest?
I'm going to test them and write a review in a few d
03.10.2016 15:29, Anastasia Lubennikova:
03.10.2016 05:22, Michael Paquier:
On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova
wrote:
Ok, I'll write it in a few days.
Marked as returned with feedback per last emails exchanged.
The only complaint about this patch was a lack of R
03.10.2016 05:22, Michael Paquier:
On Tue, Sep 27, 2016 at 12:17 AM, Anastasia Lubennikova
wrote:
Ok, I'll write it in a few days.
Marked as returned with feedback per last emails exchanged.
The only complaint about this patch was a lack of README,
which is fixed now (see the attac
But again, I have the same question.
I was confused, why do we always dump sequence data,
because I'd overlooked the --sequence-data key. I'd rather leave this
option,
because it's quite non intuitive behaviour...
/* dump sequence data even in schema-only mode */
--
Anast
24.09.2016 15:36, Amit Kapila:
On Wed, Sep 21, 2016 at 6:51 PM, Anastasia Lubennikova
wrote:
20.09.2016 08:21, Amit Kapila:
On Tue, Sep 6, 2016 at 10:18 PM, Anastasia Lubennikova
wrote:
28.08.2016 09:13, Amit Kapila:
The problem seems really tricky, but the answer is simple.
We store
important or it is simply a legasy/overlooked code?
What do you think about moving stuff from pg_upgrade/file.c to storage/file/
to allow reuse of this code? I think it'll be really helpful for
developers of contrib modules
like backup managers.
--
Anastasia Lubennikova
Postgres Professional
15.09.2016 15:29, Peter Eisentraut:
On 9/14/16 8:52 AM, Anastasia Lubennikova wrote:
Could you clarify, please, why do we dump sequence in schemaOnly mode?
+ if (dopt.schemaOnly && dopt.sequence_data)
+ getSequenceData(&dopt, tblinfo, numTables, dopt.oids);
One more update.
I added ORDER BY clause to regression tests.
It was done as a separate bugfix patch by Tom Lane some time ago,
but it definitely should be included into the patch.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, failed
Thank you for the patch.
As I see there are no objections in
28.08.2016 09:13, Amit Kapila:
On Mon, Aug 15, 2016 at 8:15 PM, Anastasia Lubennikova
wrote:
@@ -590,7 +622,14 @@ _bt_buildadd(BTWriteState *wstate, BTPageState
*state, IndexTuple itup)
if (last_off == P_HIKEY)
{
Assert(state->btps_minkey == NULL);
- state->btps_
06.09.2016 07:44, Pavan Deolasee:
On Mon, Aug 8, 2016 at 3:13 PM, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
Thank you for the review, I'll fix these problems in final version.
Posting the first message I intended to raise the discussi
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi,
I haven't tested the performance yet, but the patch itself looks pret
ompletion yet; expect things to change for items that I've overlooked,
but I hope I didn't overlook any major. If things are handwavy, it is
probably because I haven't fully figured them out yet.
Thank you again for beginning the big project.
Looking forward to the prototype. I th
09.08.2016 19:45, Andrew Borodin:
Here is new version of the patch, now it includes recommendations from
Anastasia Lubennikova.
I've investigated anamalous index size decrease. Most probable version
appeared to be true.
Cube extension, as some others, use Guttman's polynomial
looked,
but I hope I didn't overlook any major. If things are handwavy, it is
probably because I haven't fully figured them out yet.
--
Anastasia Lubennikova
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
08.08.2016 12:43, Anastasia Lubennikova:
08.08.2016 03:51, Michael Paquier:
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera
wrote:
Anastasia Lubennikova wrote:
So there is a couple of patches. They do not cover all mentioned
problems,
but I'd like to get a feedback before continuin
h expectation from the feature.
CONCLUSION==
This patch brings useful and important feature. Build shall be repaired; other
my suggestions are only suggestions.
Best regards, Andrey Borodin, Octonica & Ural Federal University.
The new status of this patch is: Waiting on Au
06.08.2016 19:51, Andrew Borodin:
Anastasia , thank you for your attentive code examine.
2016-08-05 21:19 GMT+05:00 Anastasia Lubennikova :
First of all, shouldn't we use MAXALIGN(oldsize) instead of oldsize?
Although, I'm quite sure that it was already aligned somewhere before.
I
08.08.2016 03:51, Michael Paquier:
On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote:
Anastasia Lubennikova wrote:
So there is a couple of patches. They do not cover all mentioned problems,
but I'd like to get a feedback before continuing.
I agree that we could improve things in
05.08.2016 20:56, Alvaro Herrera:
Anastasia Lubennikova wrote:
Working on page compression and some other issues related to
access methods, I found out that the code related to heap
looks too complicated. Much more complicated, than it should be.
Since I anyway got into this area, I want to
ng API
of heapam and heap relations.
You can find it on commitfest:
https://commitfest.postgresql.org/10/700/
I'll be glad to see your thoughts on the thread.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers ma
much.
And also size is reduced significantly. 89MB against 289MB without patch.
Could you explain in details, why does it happen?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
05.08.2016 16:30, Kevin Grittner:
On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova
wrote:
They can be logically separated into three categories:
"primary storage" - r, S, t, v. They store data and visibility information.
The only implementation is heapam.c
"secondary i
index
relations.
I hope these changes will be useful for the future development.
Suggested patches are mostly about renaming and rearrangement of functions
between files, so, if nobody has conceptual objections, all I need from
reviewers
is an attentive look to find typos, grammar mistak
That is not the project policy.
regards, tom lane
--
Dirk Rudolph | Senior Software Engineer
Netcentric AG
M: +41 79 642 37 11
D: +49 174 966 84 34
dirk.rudo...@netcentric.biz <mailto:dirk.rudo...@netcentric.biz> |
www.netcentric.biz <http://www.netce
tmasterMain(argc, argv);/* does not return */
#endif
And the last, but not least. Do we have any
presentations/articles/READMEs/whatever
about caches (src/backend/utils/cache/*) in postgresql?
I found nothing, besides comments in the code.
--
Anastasia Lubennikova
Postgres Professional: http://ww
the patch, I'm waiting forward
to see them.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 9c8e308..891325d 100644
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/
08.04.2016 15:45, Anastasia Lubennikova:
08.04.2016 15:06, Teodor Sigaev:
On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote:
Personally, I like documenting assertions, and will sometimes write
assertions that the compiler could easily optimize away. Maybe going
*that* far is more a matter
ommitter".
The only notice I'd like to add is about it's compatibility with
covering indexes.
We already discussed it in the thread
https://commitfest.postgresql.org/9/433/
Tiny attached patch fixes this issue.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
ecessary. Updated patch is attached
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
index 9c8e308..891325d 100644
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@
of my pgcon talk.
You know, we lost a lot of time discussing various b-tree problems.
Besides that, I am sure that the patch is really in a good shape. It
hasn't any open problems to fix.
And possible subtle bugs can be found at the testing stage of the release.
Looking forward to your
06.04.2016 16:15, Anastasia Lubennikova :
06.04.2016 03:05, Peter Geoghegan:
* There is some stray whitespace within RelationGetIndexAttrBitmap().
I think you should have updated it with code, though. I don't think
it's necessary for HOT updates to work, but I think it could be
ne
of index->ncolumns to index->nkeycolumns replacement in
match_clause_to_index. Fixed.
I also updated couple of typos in documentation.
Thank you again for the detailed review.
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
diff --git
05.04.2016 01:48, Peter Geoghegan :
On Mon, Mar 21, 2016 at 9:53 AM, Anastasia Lubennikova
wrote:
It's a bit more complicated to add it into index creation algorithm.
There's a trick with a "high key".
/*
* We copy the last item on the page into th
17.03.2016 06:27, Vitaly Burovoy:
On 2016-03-15, David Steele wrote:
On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
On 3/4/16, Anastasia Lubennikova wrote:
I think that you should update documentation. At least description of
epoch on this page:
http://www.postgresql.org/docs/devel/static
f you have any ideas related to this patch like prefix/suffix
compression, I'll be glad to discuss them.
Same for any other ideas of B-tree optimization.
--
Anastasia Lubennikova
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
21.03.2016 19:53, Anastasia Lubennikova:
19.03.2016 08:00, Peter Geoghegan:
On Fri, Mar 18, 2016 at 5:15 AM, David Steele
wrote:
It looks like this patch should be marked "needs review" and I have
done so.
Uh, no it shouldn't. I've posted an extensive review on the or
sid", so I'll take one bit of it.
It will definitely require changes in the future works on suffix
truncation or something like that, but IMHO for now it's enough.
Do you have any objections or comments?
[1] https://commitfest.postgresql.org/9/494/
--
Anastasia Lubennikov
g into pg_index, that allows to enable/disable compression
for each particular index.
4. Recheck locking considerations. I tried to write code as less
invasive as possible, but we need to make sure that algorithm is still
correct.
5. Change BTMaxItemSize
6. Bring back microvacuum functionality
15.03.2016 22:28, David Steele:
On 3/4/16 2:56 PM, Vitaly Burovoy wrote:
On 3/4/16, Anastasia Lubennikova wrote:
I think that you should update documentation. At least description of
epoch on this page:
http://www.postgresql.org/docs/devel/static/functions-datetime.html
Thank you very much
14.03.2016 16:02, David Steele:
Hi Anastasia,
On 2/18/16 12:29 PM, Anastasia Lubennikova wrote:
18.02.2016 20:18, Anastasia Lubennikova:
04.02.2016 20:16, Peter Geoghegan:
On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova
wrote:
I fixed it in the new version (attached).
Thank you
15.03.2016 03:21, Vitaly Burovoy:
On 3/14/16, Anastasia Lubennikova wrote:
14.03.2016 16:23, David Steele:
On 2/25/16 4:44 PM, Vitaly Burovoy wrote:
Added to the commitfest 2016-03.
[CF] https://commitfest.postgresql.org/9/540/
This looks like a fairly straight-forward bug fix (the size
is boundary of isoyears -4713 and -4712).
Is it worth to break undocumented range or leave it as is?
But I suppose that behavior of undocumented dates is not essential.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via
02.03.2016 08:50, Michael Paquier:
On Wed, Mar 2, 2016 at 2:10 AM, Anastasia Lubennikova
wrote:
01.03.2016 19:55, Anastasia Lubennikova:
It is not the final version, because it breaks pg_dump for previous
versions. I need some help from hackers here.
pgdump. line 5466
if (fout->remoteVers
00 00 00 00 00 00 01 00 00 00 00 00 02 00 00 00 00 00 03 00 00 00 00
00 04 00 00 00 00 00 05 00 00 00 00 00 06 00 00 00 00 00
postgres=# select bt_index_check('idx');
ERROR: cannot check index "idx"
DETAIL: index is not yet ready for insertions
But I'm sure that it's
bit sloppy
* about the maximum, since it's far enough out to not be especially
* interesting.
Maybe you can expand it?
- Is JULIAN_MAXYEAR4STAMPS helps to avoid overflow in all possible cases?
- Why do we need to hold both definitions? I suppose, it's a matter of
backward compatib
01.03.2016 19:55, Anastasia Lubennikova:
29.02.2016 18:17, Anastasia Lubennikova:
25.02.2016 21:39, Jeff Janes:
As promised, here's the new version of the patch
"including_columns_4.0".
I fixed all issues except some points mentioned below.
Thanks for the update patch. I
29.02.2016 18:17, Anastasia Lubennikova:
25.02.2016 21:39, Jeff Janes:
As promised, here's the new version of the patch
"including_columns_4.0".
I fixed all issues except some points mentioned below.
Thanks for the update patch. I get a compiler warning:
genam
ture work.
I found one more thing to do. Pgdump does not handle included columns
now. I will fix it in the next version of the patch.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hacker
18.02.2016 20:18, Anastasia Lubennikova:
04.02.2016 20:16, Peter Geoghegan:
On Fri, Jan 29, 2016 at 8:50 AM, Anastasia Lubennikova
wrote:
I fixed it in the new version (attached).
Thank you for the review.
At last, there is a new patch version 3.0. After some refactoring it
looks much
02.02.2016 15:50, Anastasia Lubennikova:
31.01.2016 11:04, David Rowley:
On 27 January 2016 at 03:35, Anastasia Lubennikova
wrote:
including_columns_3.0 is the latest version of patch.
And changes regarding the previous version are attached in a
separate patch.
Just to ease the review and
ny ideas?
If you see any related changes, please, let me know.
1.
http://www.postgresql.org/message-id/flat/56168952.4010...@postgrespro.ru#56168952.4010...@postgrespro.ru
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
31.01.2016 11:04, David Rowley:
On 27 January 2016 at 03:35, Anastasia Lubennikova
wrote:
including_columns_3.0 is the latest version of patch.
And changes regarding the previous version are attached in a separate patch.
Just to ease the review and debug.
Hi,
I've made another pass ove
29.01.2016 20:43, Thom Brown:
On 29 January 2016 at 16:50, Anastasia Lubennikova
wrote:
29.01.2016 19:01, Thom Brown:
On 29 January 2016 at 15:47, Aleksander Alekseev
wrote:
I tested this patch on x64 and ARM servers for a few hours today. The
only problem I could find is that INSERT
ied to reproduce it, but I couldn't. Debug will be much easier now.
I hope I'll fix these issueswithin the next few days.
BTW, I found a dummy mistake, the previous patch contains some unrelated
changes. I fixed it in the new version (attached).
--
Anastasia Lubennikova
Postgres Profession
28.01.2016 20:03, Thom Brown:
On 28 January 2016 at 16:12, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
28.01.2016 18:12, Thom Brown:
On 28 January 2016 at 14:06, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>> wrote:
31.0
28.01.2016 18:12, Thom Brown:
On 28 January 2016 at 14:06, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
31.08.2015 10:41, Anastasia Lubennikova:
Hi, hackers!
I'm going to begin work on effective storage of duplicate keys in
B-tree index.
31.08.2015 10:41, Anastasia Lubennikova:
Hi, hackers!
I'm going to begin work on effective storage of duplicate keys in
B-tree index.
The main idea is to implement posting lists and posting trees for
B-tree index pages as it's already done for GIN.
In a nutshell, effective
t I haven't any big machine to perform tests, where the patch is
supposed to make significant changes.
So I would rely on your and the other reviewers results.
Except mentioned notes, I suppose the patch is good enough to pass it to
a reviewer.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
25.01.2016 03:32, Jeff Janes:
On Fri, Jan 22, 2016 at 7:19 AM, Anastasia Lubennikova
wrote:
Done. I hope that my patch is close to the commit too.
Thanks for the update.
I've run into this problem:
create table foobar (x text, w text);
create unique index foobar_pkey on foob
22.01.2016 01:47, David Rowley:
On 20 January 2016 at 06:08, Anastasia Lubennikova
wrote:
18.01.2016 01:02, David Rowley пишет:
On 14 January 2016 at 08:24, David Rowley wrote:
I will try to review the omit_opclass_4.0.patch soon.
Hi, as promised, here's my review o
pending
list and then copy it again while flushing pending list into the index?
Why not read this data directly from the table? I feel that I've missed
something important here.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent
itions do not look
obvious at all.
Maybe you should explain this magic number 7 in the comment above?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
sion)
There was the discussion of the patch for partial indexes.
http://postgresql.nabble.com/PATCH-index-only-scans-with-partial-indexes-td5857568.html
Since I haven't watched it closely, It seems to be open still. I think
it'll be interesting to you.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
'll try to fix it and add expressions support a bit later.
--
Anastasia Lubennikova
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
eel renaming that might
cause a fair bit of code churn, so I'd be interested to hear what
other's have to say.
I agree that KeyAttrNumbers and indexkeys are a bit confusing names, but
I'd like to keep them at least in this patch.
It's may be worth doing "index stru
I've not looked at the EXPLAIN
code to see how those are determined yet.
Hmm... Do you use both patches?
And could you provide index definition, I can't reproduce the problem
assuming that index is created by the statement
CREATE INDEX idx ON ab (a) INCLUDING (b);
--
Anast
performing test with and whithot the patch.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
------
Index Only Scan using newidx on newt (cost=0.43..374.68 rows=1
width=8) (actual time=0.018..2.595 rows=6 loops=1)
Index Cond: (c1 < 1)
Filter: (c3 < 20)
Rows Removed by Filter: 9993
He
04.01.2016 11:49, David Rowley:
On 2 December 2015 at 01:53, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
Finally, completed patch "covering_unique_3.0.patch" is here.
It includes the functionality discussed above in the thread,
regressio
03.12.2015 04:03, Robert Haas пишет:
On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova
wrote:
If we don't need c4 as an index scankey, we don't need any btree opclass on
it.
But we still want to have it in covering index for queries like
SELECT c4 FROM tbl WHERE c1=1000; /
G (c4, c2);
Of course, order of attributes is important.
Attrs which have oplass and want to use it in ScanKey must be situated
before the others.
idx2 will use c2 in IndexCond, while idx3 will not. But I think that
it's the job for DBA.
If you see any related changes in planner, please men
08.10.2015 19:31, Thom Brown пишет:
On 8 October 2015 at 16:18, Anastasia Lubennikova
wrote:
Hi hackers,
I'm working on a patch that allows to combine covering and unique
functionality for btree indexes.
Previous discussion was here:
1) Proposal thread
2) Message with pro
1 - 100 of 136 matches
Mail list logo
