[HACKERS]WIP: Covering + unique indexes.

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; SELECT * FROM tbl WHERE c1=1000; -- Anastasia Lubennikova Postgres Professional:http://www.postgrespro.com The Russian Postgres Company test.sql Description:

Re: [HACKERS] [PATCH] Microvacuum for gist.

hange MultiDelete to TupleDelete in gistvacuumpage(). Patch is attached. But It seems to me that it would be better to rewrite all mentions of TupleDelete to MultiDelete in gist code. I'm working on it. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres C

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

ex is not unique */ int16 ind_n_key_atts; /* number of index key columns in index. counted from begin of index.*/ int16 ind_n_total_atts; /* number of columns in index.*/ In our case: ind_n_unique_atts = 2; // f1, f2 ind_n_key_atts = 3; // f1, f2, f3 ind_n_total_atts = 4; // f1, f2, f3, f4 P.S. I

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

to me. It refers to CTE, so I expect to see after that a kind of query expression. But maybe that's just matter of habit. BTW, that's the first syntax change I'm working with. Is there any convention in PostgreSQL about new keywords and so on? Where can I find it? -- Anastasia

Re: [HACKERS][PROPOSAL] Covering + unique indexes.

15.09.2015 12:18, David Rowley: On 12 September 2015 at 00:45, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: I've started work on a patch that allows to combine covering and unique functionality. Great to hear someone is working on this! Thank yo

[HACKERS][PROPOSAL] Covering + unique indexes.

of first columns of index which has unique constrains. */ I think, that numbers of all attributes themselves are not needed. Is it right? I'd like to see your suggestions about syntax changes. And of course any other comments are welcome. -- Anastasia Lubennikova Postgres Professional:

Re: [HACKERS] [PATCH] Microvacuum for gist.

: 354,097 ms Time: 82,206 ms Time: 11,714 ms Time: 11,277 ms -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/access/gist/gist.c b/src/backend/access/gist/gist.c index 0e49959..bb48782 100644 --- a/src/backend/access/gist

Re: [HACKERS] [PATCH] Microvacuum for gist.

t following queries are executed significantly faster than without microvacuum. Time: 368,780 ms Time: 69,769 ms Time: 9,545 ms Time: 12,427 ms Please, review the patch again. I could have missed something. P.S. Do I need to write any documentation update? -- Anastasia Lubennikova Postgres Pro

Re: [HACKERS] PATCH: index-only scans with partial indexes

the index->indpred, so it is impossible to recheck qual without referencing to table. In example: create index tidx_partial on t(a) where a > 1000 and a < 2000; explain analyze select sum(a) from t where a > 1000 and a < 1999; it can use IndexOnlyScan. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] [PROPOSAL] Effective storage of duplicates in B-tree index.

01.09.2015 21:23, Peter Geoghegan: On Mon, Aug 31, 2015 at 12:41 AM, Anastasia Lubennikova wrote: Now new B-tree index tuple must be inserted for each table row that we index. It can possibly cause page split. Because of MVCC even unique index could contain duplicates. Storing duplicates in

Re: [HACKERS] [PATCH] Microvacuum for gist.

Hi, I don't know too much about gist, but did a quick read through. Mostly spotting some stylistic issues. Please fix those making it easier for the next reviewer. Thank you for review! All mentioned issues are fixed. -- Anastasia Lubennikova Postgres Professional:http://www.postgrespr

Re: [HACKERS] Should \o mean "everything?"

uot; includes <...> output of various backslash commands that query the database (such as \d), | but not error messages. As I understand, this phrase means ONLY those commands which starts with '\d' (such as \dt, \di, \des etc.) -- Anastasia Lubennikova Postgres Professio

Re: [HACKERS] Adding since-version tags to the docs?

e patch author. Do you think such approach will work? Is there interest in having this done? -- Alex I think that you're looking for Feature matrix <http://www.postgresql.org/about/featurematrix/>. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

[HACKERS] [PROPOSAL] Effective storage of duplicates in B-tree index.

s to do microvacuum of posting list/tree. Which one is better? -- Anastasia Lubennikova Postgres Professional:http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] How to compare different datums within from a tuple?

> > Can someone tell me, how I can compare two datum fields, when I do not > know the data type in advance inside an executor function? > In a nutshell, there is no way to compare Datums. Datum is an abstact data type. It's the backend internal representation of a single value of any SQL data type

Re: [HACKERS] [PATCH] Microvacuum for gist.

On Mon, Aug 3, 2015 at 12:27 PM, Anastasia Lubennikova mailto:a.lubennik...@postgrespro.ru>> wrote: 1) Test and results are in attachments. Everything seems to work as expected. 2) I dropped these notices. It was done only for debug purposes. Updated patch is attached.

Re: [HACKERS] [PATCH] Microvacuum for gist.

30.07.2015 16:33, Alexander Korotkov пишет: Hi! On Thu, Jul 30, 2015 at 2:51 PM, Anastasia Lubennikova mailto:lubennikov...@gmail.com>> wrote: I have written microvacuum support for gist access method. Briefly microvacuum includes two steps: 1. When search tells us th

[HACKERS] [PATCH] Microvacuum for gist.

Hi, I have written microvacuum support for gist access method. Briefly microvacuum includes two steps: 1. When search tells us that the tuple is invisible to all transactions it is marked LP_DEAD and page is marked as "has dead tuples", 2. Then, when insert touches full page which has dead tuples

Re: [HACKERS] Microvacuum for gist. Question about GISTPageOpaqueData flag

2015-07-27 20:05 GMT+04:00 Heikki Linnakangas : > On 07/27/2015 06:46 PM, Teodor Sigaev wrote: > >> I need an advice, what would be better: >>> - to add new flag like F_HAS_GARBAGE, >>> - or to delete all mentions of F_TUPLES_DELETED and use it in gist >>> microvacuum. >>> >> >> According to commi

[HACKERS] Microvacuum for gist. Question about GISTPageOpaqueData flag

Hi, I'm working on microvacuum for gist access method. Briefly microvacuum includes two steps: 1. When search tells us that the tuple is invisible to all transactions it is marked LP_DEAD and page is marked as "has dead tuples", 2. Then, when insert touches full page which has dead tuples it calls

[HACKERS] Wrong Assert in PageIndexMultiDelete?

Hi, hackers! I am trying to create new index access method. And I found strange Assert in PageIndexMultiDelete function. Assert (nitems < MaxIndexTuplesPerPage

Re: [HACKERS] GSoC 2015 proposal. Bitmap Index-only Count

2015-03-24 18:01 GMT+04:00 Tom Lane : > Anastasia Lubennikova writes: > > There is a problem of slow counting in PostgreSQL [1]. The reason why > this > > is slow is related to the *MVCC* implementation in PostgreSQL. Index-only > > scans (implemented since Postgr

[HACKERS] GSoC 2015 proposal. Bitmap Index-only Count

Hi, hackers! Here is the text of my proposal which I've applied to GSoC. (and link http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/lubennikovaav/5657382461898752 ) Any suggestions and comments are welcome. *Project name* Bitmap Index-only Count *Brief review* There is a p

Re: [HACKERS] Index-only scans for GiST.

I add MemoryContext listCxt to avoid memory leak. listCxt is created once in gistrescan (only for index-only scan plan ) and reseted when scan of the leaf page is finished. I do not sure if the problem was completely solved, so I wait for feedback. * What's the reason for turning GISTScanOpaqueDa

Re: [HACKERS] Index-only scans for GiST.

Thanks for answer. Now it seems to be applied correctly. 2015-02-12 3:12 GMT+04:00 Thom Brown : > On 11 February 2015 at 22:50, Anastasia Lubennikova < > lubennikov...@gmail.com> wrote: > >> Finally there is a new version of patch (in attachments). >> It provides mult

[HACKERS] Index-only scans for GiST.

Finally there is a new version of patch (in attachments). It provides multicolumn index-only scan for GiST indexes. - Memory leak is fixed. - little code cleanup - example of performance test in attachmens - function OIDs have debugging values (*) just to avoid merge conflicts while testing pa

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

I'm interested to participate as student again. -- Best regards, Lubennikova Anastasia

Re: [HACKERS] Index-only scans for GIST

Updated patch * Compiler, merge and regression fails checked * Regression tests was impoved * GiST and amcanreturn docs updated -- Best regards, Lubennikova Anastasia indexonlyscan_gist2.patch Description: Binary data indexonlyscan_gist_docs.patch Description: Binary data -- Sent via pgsql-h

Re: [HACKERS] Index-only scans for GIST

2014-08-07 0:30 GMT+04:00 Heikki Linnakangas : * I'm getting two regression failures with this (opr_sanity and join). > opr_sanity failure is corrected. But there is remain question with join. I check the latest version of my github repo and there's no fail in join regression test All 145 tests p

Re: [HACKERS] Index-only scans for GIST

Thank you for comment Patch is already added in Performance topic. 2014-08-01 20:25 GMT+04:00 Fabrízio de Royes Mello : > > On Fri, Aug 1, 2014 at 4:58 AM, Anastasia Lubennikova < > lubennikov...@gmail.com> wrote: > > > > Hi, hackers! > > I work on a GSoC p

[HACKERS] Index-only scans for GIST

Hi, hackers! I work on a GSoC project "Index-only scans for GIST" https://wiki.postgresql.org/wiki/Support_for_Index-only_scans_for_GIST_GSoC_2014 Repository is https://github.com/lubennikovaav/postgres/tree/indexonlygist2 Patch is in attachments. It includes index-only scans for multicolumn GIST

[HACKERS] Index-only scans for multicolumn GIST

Hi, hackers! There are new results of my work on GSoC project "Index-only scans for GIST". Previous post is here: http://postgresql.1045698.n5.nabble.com/Index-only-scans-for-GIST-td5804892.html Repository is https://github.com/lubennikovaav/postgres/tree/indexonlygist2 Patch is in attachments. It

[HACKERS] Changes in amcanreturn() interface to support multicolumn indexes

Changes in amcanreturn() interface to support multicolumn indexes. Hi, hackers I work on GSoC project Support_for_Index-only_scans_for_GIST_GSoC_2014 There is a question of support multicolumn index only scans for GI

[HACKERS] Index-only scans for GIST

Hi, hackers! There are first results of my work on GSoC project "Index-only scans for GIST". 1. Version of my project code is in forked repository https://github.com/lubennikovaav/postgres/tree/indexonlygist2 Patch is in attachments - This version is only for one-column indexes - fetch() method is

Re: [HACKERS] GSoC proposal. Index-only scans for GIST

2014-03-18 18:47 GMT+04:00 Robert Haas > > > > If the fetch() is specified by the developer, then using it, algorithm > can > > retrieve the data directly to output areas at this stage, without > reference > > to the heap. > > This seems to be the crux of your proposal, but it seems vague: what >

[HACKERS] GSoC proposal. Index-only scans for GIST

Hello! Here is the text of my proposal which I've applied to GSoC. (and link http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/lubennikovaav/5629499534213120) Any suggestions and comments are welcome. *Project name* Support for index-only scans for GIST index *Brief review* C

<    1   2