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 use many ideas from discussion without quotations just becau
. 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 Lubennikova
Postgres
15.09.2015 12:18, David Rowley:
On 12 September 2015 at 00:45, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru <mailto:a.lubennik...@postgrespro.ru>>
wrote:
I've started work on a patch that allows to combine covering and
unique functionality.
Great to hear someon
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:http://www.postgrespro.com
: 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
han 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 Professional: http://www.postgrespro.com
The Russian Postg
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
Postgr
01.09.2015 21:23, Peter Geoghegan:
On Mon, Aug 31, 2015 at 12:41 AM, Anastasia Lubennikova
<a.lubennik...@postgrespro.ru> 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
c
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.postgrespro.com
s.
As I understand, this phrase means ONLY those commands which starts with
'\d' (such as \dt, \di, \des etc.)
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
t/tree.
Which one is better?
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
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
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.
On Mon, Aug 3, 2015 at 12:27 PM, Anastasia Lubennikova
a.lubennik...@postgrespro.ru 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
30.07.2015 16:33, Alexander Korotkov пишет:
Hi!
On Thu, Jul 30, 2015 at 2:51 PM, Anastasia Lubennikova
lubennikov...@gmail.com mailto:lubennikov...@gmail.com wrote:
I have written microvacuum support for gist access method.
Briefly microvacuum includes two steps:
1. When search
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
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
2015-07-27 20:05 GMT+04:00 Heikki Linnakangas hlinn...@iki.fi:
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 commit
Hi, hackers!
I am trying to create new index access method.
And I found strange Assert in PageIndexMultiDelete
http://doxygen.postgresql.org/bufpage_8c_source.html#l00791 function.
Assert
http://doxygen.postgresql.org/c_8h.html#a706ac5b1a53bd04067f81924b92cb9f6(nitems
MaxIndexTuplesPerPage
2015-03-24 18:01 GMT+04:00 Tom Lane t...@sss.pgh.pa.us:
Anastasia Lubennikova lubennikov...@gmail.com 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
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
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
Thanks for answer.
Now it seems to be applied correctly.
2015-02-12 3:12 GMT+04:00 Thom Brown t...@linux.com:
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 multicolumn index-only scan
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
I'm interested to participate as student again.
--
Best regards,
Lubennikova Anastasia
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
2014-08-07 0:30 GMT+04:00 Heikki Linnakangas hlinnakan...@vmware.com:
* 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
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
Thank you for comment
Patch is already added in Performance topic.
2014-08-01 20:25 GMT+04:00 Fabrízio de Royes Mello fabriziome...@gmail.com
:
On Fri, Aug 1, 2014 at 4:58 AM, Anastasia Lubennikova
lubennikov...@gmail.com wrote:
Hi, hackers!
I work on a GSoC project Index-only scans
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
Changes in amcanreturn() interface to support multicolumn indexes.
Hi, hackers
I work on GSoC project Support_for_Index-only_scans_for_GIST_GSoC_2014
https://wiki.postgresql.org/wiki/Support_for_Index-only_scans_for_GIST_GSoC_2014
There is a question of support multicolumn index only scans for
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
2014-03-18 18:47 GMT+04:00 Robert Haas robertmh...@gmail.com
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
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*
101 - 134 of 134 matches
Mail list logo