On 4/2/16 4:21 PM, Konstantin Knizhnik wrote:
> Thank you for review, Tom.
>
> I completely agree with all your arguments against this patch.
> I have proposed this patch mostly as prove of concept.
I have marked this "returned with feedback". Hopefully you can work on
the concept and resubmit
On 04/02/2016 09:57 PM, Tom Lane wrote:
Konstantin Knizhnik writes:
Attached please find patch for "ALTER INDEX ... WHERE ..." clause.
It is now able to handle all three possible situations:
1. Making index partial (add WHERE condition to the ordinary index)
2. Extend partial index range (less
Konstantin Knizhnik writes:
> Attached please find patch for "ALTER INDEX ... WHERE ..." clause.
> It is now able to handle all three possible situations:
> 1. Making index partial (add WHERE condition to the ordinary index)
> 2. Extend partial index range (less restricted index predicate)
> 3. Ar
On 3/14/16 10:37 AM, David Steele wrote:
On 3/14/16 10:28 AM, Konstantin Knizhnik wrote:
Rebased patch is attached.
Thanks for the quick turnaround!
Marko, you are signed up to review this patch. Do you have an idea of
when you'll be able to do that?
Bump.
Since it looks like Marko has n
On 3/14/16 10:28 AM, Konstantin Knizhnik wrote:
Rebased patch is attached.
Thanks for the quick turnaround!
Marko, you are signed up to review this patch. Do you have an idea of
when you'll be able to do that?
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-h
Hi David,
Rebased patch is attached.
On 14.03.2016 15:09, David Steele wrote:
Hi Konstantin,
On 2/3/16 11:47 AM, Konstantin Knizhnik wrote:
Attached please find patch for "ALTER INDEX ... WHERE ..." clause.
It is now able to handle all three possible situations:
1. Making index partial (add W
Hi Konstantin,
On 2/3/16 11:47 AM, Konstantin Knizhnik wrote:
Attached please find patch for "ALTER INDEX ... WHERE ..." clause.
It is now able to handle all three possible situations:
1. Making index partial (add WHERE condition to the ordinary index)
2. Extend partial index range (less restric
On 2/4/16 1:37 AM, konstantin knizhnik wrote:
>My suspicion is that it would be useful to pre-order the new data before
trying to apply it to the indexes.
Sorry, but ALTER INDEX is expected to work for all indexes, not only B-Tree,
and for them sorting may not be possible...
But for B-Tree pre
On Feb 4, 2016, at 2:00 AM, Jim Nasby wrote:
>
> My suspicion is that it would be useful to pre-order the new data before
> trying to apply it to the indexes.
Sorry, but ALTER INDEX is expected to work for all indexes, not only B-Tree,
and for them sorting may not be possible...
But for B-Tre
On 1/21/16 11:47 AM, Konstantin Knizhnik wrote:
BTW, could you explain, what is the reason to copy data into the
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.
No,
Attached please find patch for "ALTER INDEX ... WHERE ..." clause.
It is now able to handle all three possible situations:
1. Making index partial (add WHERE condition to the ordinary index)
2. Extend partial index range (less restricted index predicate)
3. Arbitrary change of partial index predic
On Wed, Jan 20, 2016 at 4:28 AM, Konstantin Knizhnik
wrote:
> Please notice that such alter table statement, changing condition for
> partial index, is not supported now.
> But I do not see any principle problems with supporting such construction.
> We should just include in the index all records
Hi hackers,
I have implemented "ALTER INDEX ... WHERE ..." clause allowing to change
condition for partial index.
Actually it allows us to append index without fully rebuilding it.
As I explained in the previous mails, partial indexes can be used to
increase insert speed.
Right now I get the
On 21.01.2016 18:47, Konstantin Knizhnik wrote:
On 21.01.2016 19:09, Anastasia Lubennikova wrote:
What I meant is more like a BRIN-like combination of an index scan and
heap scan.
Maybe it could be called "deferred inserts" or "temporary read-only
index"
Maybe it's similar with mysql insert bu
On 21.01.2016 19:09, Anastasia Lubennikova wrote:
What I meant is more like a BRIN-like combination of an index scan and
heap scan.
Maybe it could be called "deferred inserts" or "temporary read-only
index"
Maybe it's similar with mysql insert buffer
http://dev.mysql.com/doc/refman/5.7/en/inn
On 21.01.2016 10:14, Simon Riggs wrote:
On 21 January 2016 at 06:41, konstantin knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Certainly for B-Tree we can organize insert buffer (or pending
list) as sorted array or also as a tree.
But in both case complexity of search in this
20.01.2016 17:55, Konstantin Knizhnik:
Hi,
Hi, I glad to see that you interested in that too.
I think this is a good feature and I think it will be very useful to
have.
I have already mentioned some related problems and possible
improvements in my presentation.
http://www.slideshare.net/Anas
On 21 January 2016 at 06:41, konstantin knizhnik
wrote:
> Certainly for B-Tree we can organize insert buffer (or pending list) as
> sorted array or also as a tree.
> But in both case complexity of search in this buffer will be O(log(N)),
> not O(1).
>
You are right; search within this buffer is
On Jan 21, 2016, at 5:14 AM, Simon Riggs wrote:
> On 20 January 2016 at 14:55, Konstantin Knizhnik
> wrote:
> Hi,
>
> Hi, I glad to see that you interested in that too.
> I think this is a good feature and I think it will be very useful to have.
> I have already mentioned some related problems
On 20 January 2016 at 14:55, Konstantin Knizhnik
wrote:
> Hi,
>
> Hi, I glad to see that you interested in that too.
>> I think this is a good feature and I think it will be very useful to have.
>> I have already mentioned some related problems and possible improvements
>> in my presentation.
>>
Hi,
Hi, I glad to see that you interested in that too.
I think this is a good feature and I think it will be very useful to have.
I have already mentioned some related problems and possible
improvements in my presentation.
http://www.slideshare.net/AnastasiaLubennikova/indexes-dont-mean-slow-i
20.01.2016 12:28, Konstantin Knizhnik :
Hi hackers,
I want to know opinion of community about possible ways of solving
quite common problem: increasing insert speed while still providing
indexes for efficient execution of queries.
Many applications have to deal with high input stream of data
Hi hackers,
I want to know opinion of community about possible ways of solving quite
common problem: increasing insert speed while still providing indexes
for efficient execution of queries.
Many applications have to deal with high input stream of data. Most of
the time while record insertin
On Tue, 2008-02-26 at 09:08 +, Simon Riggs wrote:
> I very much like the idea of index merging, or put another way: batch
> index inserts. How big do the batch of index inserts have to be for us
> to gain benefit from this technique? Would it be possible to just buffer
> the index inserts insi
Added to TODO:
o Allow COPY FROM to create index entries in bulk
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php
---
ITAGAKI Takahiro wrote:
> This is a proposal of fast data loading us
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>>> Can we do REINDEX
>>> holding only shared lock on the index?
>>
>> No. When you commit the reindex, the old copy of the index will
>> instantaneously disappear; it will not do for someone to be actively
>> scan
Tom Lane <[EMAIL PROTECTED]> wrote:
> > Can we do REINDEX
> > holding only shared lock on the index?
>
> No. When you commit the reindex, the old copy of the index will
> instantaneously disappear; it will not do for someone to be actively
> scanning that copy.
Hmm... Is it ok if the index wil
"Markus Bertheau" <[EMAIL PROTECTED]> writes:
> 2008/2/29, Tom Lane <[EMAIL PROTECTED]>:
>> No. When you commit the reindex, the old copy of the index will
>> instantaneously disappear; it will not do for someone to be actively
>> scanning that copy.
> Can a shared lock be taken at first, and whe
2008/2/29, Tom Lane <[EMAIL PROTECTED]>:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > BTW, why REINDEX requires access exclusive lock? Read-only queries
> > are forbidden during the operation now, but I feel they are ok
> > because REINDEX only reads existing tuples. Can we do REINDEX
> >
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> BTW, why REINDEX requires access exclusive lock? Read-only queries
> are forbidden during the operation now, but I feel they are ok
> because REINDEX only reads existing tuples. Can we do REINDEX
> holding only shared lock on the index?
No. When you
Simon Riggs <[EMAIL PROTECTED]> wrote:
> The LOCK is only required because we defer the inserts into unique
> indexes, yes?
No, as far as present pg_bulkload. It creates a new relfilenode like REINDEX,
therefore, access exclusive lock is needed. When there is violations of
unique constraints, al
On Tue, 2008-02-26 at 15:19 +0900, ITAGAKI Takahiro wrote:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > One of the reasons why I hadn't wanted to pursue earlier ideas to use
> > LOCK was that applying a lock will prevent running in parallel, which
> > ultimately may prevent further performance g
Simon Riggs <[EMAIL PROTECTED]> wrote:
> One of the reasons why I hadn't wanted to pursue earlier ideas to use
> LOCK was that applying a lock will prevent running in parallel, which
> ultimately may prevent further performance gains.
>
> Is there a way of doing this that will allow multiple conc
On Thu, 2008-02-21 at 13:26 +0900, ITAGAKI Takahiro wrote:
> This is a proposal of fast data loading using batch update of indexes for 8.4.
> It is a part of pg_bulkload (http://pgbulkload.projects.postgresql.org/) and
> I'd like to integrate it in order to cooperate with other parts of postgres.
>
Itagaki-san,
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > The basic concept is spooling new coming data, and merge the spool and
> > > the existing indexes into a new index at the end of data loading. It is
> > > 5-10 times faster than index insertion per-row, that is the way in 8.3.
Thanks
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > The basic concept is spooling new coming data, and merge the spool and
> > the existing indexes into a new index at the end of data loading. It is
> > 5-10 times faster than index insertion per-row, that is the way in 8.3.
>
> Please see
> http://th
ITAGAKI Takahiro wrote:
> The basic concept is spooling new coming data, and merge the spool and
> the existing indexes into a new index at the end of data loading. It is
> 5-10 times faster than index insertion per-row, that is the way in 8.3.
Please see
http://thread.gmane.org/gmane.comp.db.p
This is a proposal of fast data loading using batch update of indexes for 8.4.
It is a part of pg_bulkload (http://pgbulkload.projects.postgresql.org/) and
I'd like to integrate it in order to cooperate with other parts of postgres.
The basic concept is spooling new coming data, and merge the spoo
38 matches
Mail list logo
