On Thu, Apr 3, 2014 at 7:26 AM, Heikki Linnakangas
wrote:
> On 04/01/2014 08:39 PM, Heikki Linnakangas wrote:
>> On 03/07/2014 05:36 AM, Tom Lane wrote:
>>> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
>>> writes:
Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED"
too?
Heikki Linnakangas writes:
> No-one's replied yet, but perhaps the worry is that after you've written
> the commit record, you have to go ahead with removing/creating the init
> fork, and that is seen as too risky. If a creat() or unlink() call
> fails, that will have to be a PANIC, and crash r
On 2014-04-03 15:02:27 +0300, Heikki Linnakangas wrote:
> On 04/03/2014 02:41 PM, Andres Freund wrote:
> >On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
> >>On 04/01/2014 08:58 PM, Andres Freund wrote:
> >>>On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
> On 3/4/14, 8:50 AM, Andres Fre
On 04/03/2014 02:41 PM, Andres Freund wrote:
On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
On 04/01/2014 08:58 PM, Andres Freund wrote:
On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relatio
On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
> On 04/01/2014 08:58 PM, Andres Freund wrote:
> >On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
> >>On 3/4/14, 8:50 AM, Andres Freund wrote:
> >>>Can't that be solved by just creating the permanent relation in a new
> >>>relfilenode? That's e
On 2014-04-03 14:26:50 +0300, Heikki Linnakangas wrote:
> On 04/01/2014 08:39 PM, Heikki Linnakangas wrote:
> >On 03/07/2014 05:36 AM, Tom Lane wrote:
> >>=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> >>>Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
> >>>Thinkin
On 04/01/2014 08:39 PM, Heikki Linnakangas wrote:
On 03/07/2014 05:36 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
Thinking in a scope of one GSoC, of course.
I think it's basically the same
On 2014-04-01 20:39:35 +0300, Heikki Linnakangas wrote:
> On 03/07/2014 05:36 AM, Tom Lane wrote:
> >=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> >>Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
> >>Thinking in a scope of one GSoC, of course.
> >
> >I think it's
On 04/03/2014 01:44 PM, Andres Freund wrote:
On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
On 04/01/2014 08:58 PM, Andres Freund wrote:
On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relatio
On 2014-04-03 13:38:29 +0300, Heikki Linnakangas wrote:
> On 04/01/2014 08:58 PM, Andres Freund wrote:
> >On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
> >>On 3/4/14, 8:50 AM, Andres Freund wrote:
> >>>Can't that be solved by just creating the permanent relation in a new
> >>>relfilenode? That's e
On 04/01/2014 08:58 PM, Andres Freund wrote:
On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relation in a new
relfilenode? That's equivalent to a rewrite, yes, but we need to do that
for anything but wa
On Tue, Apr 1, 2014 at 1:40 PM, Andres Freund
wrote:
>
> On 2014-04-01 13:37:57 -0300, Fabrízio de Royes Mello wrote:
> > In the GSoC proposal page [1] I received some suggestions to strech
goals:
> >
> > * "ALTER TABLE name SET UNLOGGED". This is essentially the reverse of
the
> > core proposal,
On 2014-04-01 12:56:04 -0500, Jim Nasby wrote:
> On 3/4/14, 8:50 AM, Andres Freund wrote:
> >Can't that be solved by just creating the permanent relation in a new
> >relfilenode? That's equivalent to a rewrite, yes, but we need to do that
> >for anything but wal_level=minimal anyway.
>
> Maybe I'm
On 3/4/14, 8:50 AM, Andres Freund wrote:
Can't that be solved by just creating the permanent relation in a new
relfilenode? That's equivalent to a rewrite, yes, but we need to do that
for anything but wal_level=minimal anyway.
Maybe I'm missing something, but doesn't this actually involve writi
On 03/07/2014 05:36 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
Thinking in a scope of one GSoC, of course.
I think it's basically the same thing. You might hope to optimize it;
but you have
On 2014-04-01 13:37:57 -0300, Fabrízio de Royes Mello wrote:
> In the GSoC proposal page [1] I received some suggestions to strech goals:
>
> * "ALTER TABLE name SET UNLOGGED". This is essentially the reverse of the
> core proposal, which is "ALTER TABLE name SET LOGGED". Yes, I think that
> shoul
On Fri, Mar 7, 2014 at 12:36 AM, Tom Lane wrote:
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
> writes:
> > Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED"
> too?
> > Thinking in a scope of one GSoC, of course.
>
> I think it's basically the same thing. You might hope to o
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
>
On 03/18/2014 12:11 PM, Alexander Korotkov wrote:
> Josh,
>
> Anastasia has already consulted to me in person. It is not big proposal.
> But for newbie who is not familiar with PostgreSQL code base and especially
> GiST it seems fair enough.
>
Thanks, that's what I wanted to know.
--
Josh Berk
Josh,
Anastasia has already consulted to me in person. It is not big proposal.
But for newbie who is not familiar with PostgreSQL code base and especially
GiST it seems fair enough.
With best regards,
Alexander Korotkov.
On Tue, Mar 18, 2014 at 9:16 PM, Josh Berkus wrote:
> Alexander,
>
>
On Tue, Mar 18, 2014 at 5:12 PM, Anastasia Lubennikova <
lubennikov...@gmail.com> wrote:
> 2. gistget algorithm (several parts omitted):
>
> Check the key
> gistindex_keytest() - does this index tuple satisfy the scan key(s)?
>
> Scan all items on the GiST index page and insert them into the queue
Alexander,
Can you comment on the below proposal? I'd like your opinion on how
difficult it will be.
On 03/18/2014 06:12 AM, Anastasia Lubennikova wrote:
> 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
Robert Haas writes:
> Tom Lane previously proposed extending SP-GiST to support index-only
> scans. You might find that discussing worth reading, or perhaps
> consider it as an alternative if GiST doesn't work out:
> http://www.postgresql.org/message-id/10839.1323885...@sss.pgh.pa.us
That wasn't
On Tue, Mar 18, 2014 at 9:12 AM, Anastasia Lubennikova
wrote:
> Support for index-only scans for GIST index
This is a cool idea, if it can be made to work.
> If the fetch() is specified by the developer, then using it, algorithm can
> retrieve the data directly to output areas at this stage, wit
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
On Fri, Mar 7, 2014 at 12:36 AM, Tom Lane wrote:
>
> =?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?=
writes:
> > Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED"
too?
> > Thinking in a scope of one GSoC, of course.
>
> I think it's basically the same thing. You might hope to opti
=?ISO-8859-1?Q?Fabr=EDzio_de_Royes_Mello?= writes:
> Do you think is difficult to implement "ALTER TABLE ... SET UNLOGGED" too?
> Thinking in a scope of one GSoC, of course.
I think it's basically the same thing. You might hope to optimize it;
but you have to create (rather than remove) an init
On Thu, Mar 6, 2014 at 5:04 PM, Robert Haas wrote:
>
> On Thu, Mar 6, 2014 at 2:52 PM, Fabrízio de Royes Mello
> wrote:
> > On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas
wrote:
> >> I think this isn't a good design. Per the discussion between Andres
> >> and I, I think that I think you should do
On Thu, Mar 6, 2014 at 5:05 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Thu, Mar 6, 2014 at 5:04 PM, Robert Haas wrote:
> >
> > On Thu, Mar 6, 2014 at 2:52 PM, Fabrízio de Royes Mello
> > wrote:
> > > On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas
wrote:
> > >> I think th
On Thu, Mar 6, 2014 at 5:04 PM, Robert Haas wrote:
>
> On Thu, Mar 6, 2014 at 2:52 PM, Fabrízio de Royes Mello
> wrote:
> > On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas
wrote:
> >> I think this isn't a good design. Per the discussion between Andres
> >> and I, I think that I think you should do
On Thu, Mar 6, 2014 at 2:52 PM, Fabrízio de Royes Mello
wrote:
> On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas wrote:
>> I think this isn't a good design. Per the discussion between Andres
>> and I, I think that I think you should do is make ALTER TABLE .. SET
>> LOGGED work just like VACUUM FULL,
On Thu, Mar 6, 2014 at 4:42 PM, Robert Haas wrote:
>
>
> I think this isn't a good design. Per the discussion between Andres
> and I, I think that I think you should do is make ALTER TABLE .. SET
> LOGGED work just like VACUUM FULL, with the exception that it will set
> a different relpersistence
On 6 March 2014 19:42, Robert Haas wrote:
> On Wed, Mar 5, 2014 at 7:42 PM, Fabrízio de Royes Mello
> wrote:
> > On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello
> > wrote:
> >> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund
> >> wrote:
> >> >
> >> > On 2014-03-04 12:54:02 -0500, Robert
On Wed, Mar 5, 2014 at 7:42 PM, Fabrízio de Royes Mello
wrote:
> On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello
> wrote:
>> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund
>> wrote:
>> >
>> > On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
>> > > On Tue, Mar 4, 2014 at 9:50 AM, Andres Fr
On Tue, Mar 4, 2014 at 5:00 PM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
>
> On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund
wrote:
> >
> > On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
> > > On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund
wrote:
> > > > On 2014-03-04 09:47:08 -
On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund
wrote:
>
> On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
> > On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund
wrote:
> > > On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
> > > Can't that be solved by just creating the permanent relation in a new
> >
On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
> On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund wrote:
> > On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
> > Can't that be solved by just creating the permanent relation in a new
> > relfilenode? That's equivalent to a rewrite, yes, but we need t
On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund wrote:
> On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
>> On Mon, Mar 3, 2014 at 12:08 PM, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
>> >> wrote:
>> >> > I
On Tue, Mar 4, 2014 at 11:50 AM, Andres Freund
wrote:
>
> On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
> > On Mon, Mar 3, 2014 at 12:08 PM, Stephen Frost
wrote:
> > > * Robert Haas (robertmh...@gmail.com) wrote:
> > >> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
> > >> wrote:
>
On Tue, Mar 4, 2014 at 3:31 AM, Andres Freund
wrote:
>
> On 2014-03-04 01:10:50 -0300, Fabrízio de Royes Mello wrote:
> > Today I do something like that:
> >
> > 1) create unlogged table tmp_foo ...
> > 2) populate 'tmp_foo' table (ETL scripts or whatever)
> > 3) start transaction
> > 4) lock tabl
On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
> On Mon, Mar 3, 2014 at 12:08 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
> >> wrote:
> >> > Is the TODO item "make an unlogged table logged" [1] a good GS
On Mon, Mar 3, 2014 at 12:08 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
>> wrote:
>> > Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
>>
>> I'm pretty sure we found some problems in
On 2014-03-04 01:10:50 -0300, Fabrízio de Royes Mello wrote:
> Today I do something like that:
>
> 1) create unlogged table tmp_foo ...
> 2) populate 'tmp_foo' table (ETL scripts or whatever)
> 3) start transaction
> 4) lock table tmp_foo in access exclusive mode
> 5) update pg_class set relpersis
On Mon, Mar 3, 2014 at 2:42 PM, Andres Freund
wrote:
>
> On 2014-03-03 12:08:26 -0500, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
> > > wrote:
> > > > Is the TODO item "make an unlogged table logged" [1] a g
On Mon, Mar 3, 2014 at 5:47 PM, Andres Freund
wrote:
>
> On 2014-03-03 12:44:26 -0800, Peter Geoghegan wrote:
> > On Mon, Mar 3, 2014 at 8:28 AM, Fabrízio de Royes Mello
> > wrote:
> > > Is the TODO item "make an unlogged table logged" [1] a good GSoC
project?
> >
> > Another interesting project
On Mon, Mar 3, 2014 at 5:44 PM, Peter Geoghegan wrote:
>
> On Mon, Mar 3, 2014 at 8:28 AM, Fabrízio de Royes Mello
> wrote:
> > Is the TODO item "make an unlogged table logged" [1] a good GSoC
project?
>
> Another interesting project around unlogged tables would be to make it
> possible to have u
On Mon, Mar 3, 2014 at 2:40 PM, Hannu Krosing wrote:
>
> On 03/03/2014 05:22 PM, Tom Lane wrote:
> > Stephen Frost writes:
> ...
> >> ISTR the discussion going something along the lines of "we'd have to
WAL
> >> log the entire table to do that, and if we have to do that, what's the
> >> point?".
On 2014-03-03 12:44:26 -0800, Peter Geoghegan wrote:
> On Mon, Mar 3, 2014 at 8:28 AM, Fabrízio de Royes Mello
> wrote:
> > Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
>
> Another interesting project around unlogged tables would be to make it
> possible to have unlog
On Mon, Mar 3, 2014 at 8:28 AM, Fabrízio de Royes Mello
wrote:
> Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
Another interesting project around unlogged tables would be to make it
possible to have unlogged indexes on fully-logged tables. That is
something that there
On 2014-03-03 12:08:26 -0500, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
> > wrote:
> > > Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
> >
> > I'm pretty sure we found some problems
On 03/03/2014 05:22 PM, Tom Lane wrote:
> Stephen Frost writes:
...
>> ISTR the discussion going something along the lines of "we'd have to WAL
>> log the entire table to do that, and if we have to do that, what's the
>> point?".
> IIRC, the reason you'd have to do that is to make the table conten
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
>> wrote:
>>> Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
>> I'm pretty sure we found some problems in that design that we couldn't
>> fi
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
> wrote:
> > Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
>
> I'm pretty sure we found some problems in that design that we couldn't
> figure out how to solve. I d
On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
wrote:
> Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
I'm pretty sure we found some problems in that design that we couldn't
figure out how to solve. I don't have a pointer to the relevant
-hackers discussion o
Hi all,
Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
Regards,
[1]
http://www.postgresql.org/message-id/aanlktinenzbrxdcwohkqbba2bhubfy8_c5jwrxlod...@mail.gmail.com
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> B
> I'm applying for GSoC 2014 with Postgresql and would appreciate your comments
> on my proposal
> (attached). I'm looking for technical corrections/comments and your opinions
> on the project's
> viability. In particular, if the community has doubts about its usefulness, I
> would start working
On Feb28, 2014, at 05:29 , Tan Tran wrote:
> I'm applying for GSoC 2014 with Postgresql and would appreciate your comments
> on my proposal (attached).
>
First, please include your proposal as plain, inline text next time.
That makes it easier to quote the relevant parts when replying, and
also
2011/4/5 Masanori Yamazaki :
> Hello
>
> I am sending my proposal about Google Summer Of Code2011.
> It would be nice if you could give me your opinion.
Fantastic! Please submit your proposal through the GSoC website:
http://www.google-melange.com/gsoc/profile/student/google/gsoc2011
-selena
2011/4/7 Tatsuo Ishii :
> In my understanding pqc is not designed to be working with pgpool.
> Thus if a user want to use both query cache and query dispatching,
> replication or failover etc. which are provided by pgpool, it seems
> it's not possible. For this purpose maybe user could *cascade* pq
In my understanding pqc is not designed to be working with pgpool.
Thus if a user want to use both query cache and query dispatching,
replication or failover etc. which are provided by pgpool, it seems
it's not possible. For this purpose maybe user could *cascade* pqc and
pgpool, but I'm not sure.
I like this proposal. This would bring big benefit to both the
PostgreSQL and the pgpool project.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> Hello
>
> I am sending my proposal about Google Summer Of Code2011.
> It would b
Hello
I am sending my proposal about Google Summer Of Code2011.
It would be nice if you could give me your opinion.
・title
Caching query results in pgpool-II
・Synopsis
Pgpool-II has query caching functionality using storage provided by
dedicated PostgreSQL ("system database"). This has sever
How does this relate to the existing pqc project (
http://code.google.com/p/pqc/)? Seems the goals are fairly similar, and both
are based off pgpool?
/Magnus
On Apr 6, 2011 2:10 AM, "Masanori Yamazaki" wrote:
> Hello
>
> My name is Masanori Yamazaki. I am sending my proposal about
> Google Summe
Just to clarify situation a bit. I noticed buffer tree technique while
reseaching
sp-gist and got an idea to use it for improving CREATE INDEX for GiST, which
is what we were looking many times. Alexander is working on his thesis and
this project suits ideally for him and community. Since I and
Hello
My name is Masanori Yamazaki. I am sending my proposal about
Google Summer Of Code2011. It would be nice if you could give
me your opinion.
・title
Caching query results in pgpool-II
・Synopsis
Pgpool-II has query caching functionality using storage provided by
dedicated PostgreSQL ("sy
On Mon, Apr 4, 2011 at 8:50 PM, Robert Haas wrote:
> OK. Could you briefly describe the algorithm you propose to
> implement, bearing in mind that I haven't read the paper?
>
The technique can be very briefly described in following rules.
M = number of index keys fitting in RAM;
B = number of i
On Mon, Apr 4, 2011 at 12:46 PM, Alexander Korotkov
wrote:
> On Mon, Apr 4, 2011 at 7:04 PM, Robert Haas wrote:
>>
>> On Mon, Apr 4, 2011 at 7:16 AM, Alexander Korotkov
>> wrote:
>> > Project name
>> > Fast GiST index build
>>
>> Would/could/should this be implemented in a manner similar to the
On Mon, Apr 4, 2011 at 7:04 PM, Robert Haas wrote:
> On Mon, Apr 4, 2011 at 7:16 AM, Alexander Korotkov
> wrote:
> > Project name
> > Fast GiST index build
>
> Would/could/should this be implemented in a manner similar to the
> existing "GIN fast update" feature?
>
I've mentioned this problem i
Robert Haas writes:
> On Mon, Apr 4, 2011 at 7:16 AM, Alexander Korotkov
> wrote:
>> Project name
>> Fast GiST index build
> Would/could/should this be implemented in a manner similar to the
> existing "GIN fast update" feature?
Fast build and fast update tend to be two different problems ...
On Mon, Apr 4, 2011 at 7:16 AM, Alexander Korotkov wrote:
> Project name
> Fast GiST index build
Would/could/should this be implemented in a manner similar to the
existing "GIN fast update" feature?
It's occurred to me to wonder whether even btree indexes would benefit
from this type of optimiza
Hello!
Here is the text of my proposal which I've recently applied to GSoC and have
mentioned before in
http://archives.postgresql.org/message-id/AANLkTimqFRmFdrYaesnJB8H4BuJo3j1SBdR1qmv=k...@mail.gmail.com
Any comments are welcome.
*Project name*
Fast GiST index build
*Synopsis*
Currently GiS
2010/4/20 Pavel :
> For now I know it is not commitable in actual state, but for my thesis it is
> enough and I know it will not be commitable with this design at all. In case
> of GSoC it will depends on the time I will be able to spend on it, if I will
> consider some other design.
I am not sure
Greg Smith wrote:
pavelbaros wrote:
I am also waiting for approval for my repository named
"materialized_view" on git.postgresql.org, so I could publish
completed parts.
Presuming that you're going to wander there and get assigned what
looks like an official repo name for this project is a
Josh Berkus writes:
> There are basically 2 major parts for materialized views:
> A) Planner: Getting the query planner to swap in the MatView for part of
> a query automatically for query plan portions which the MatView supports;
> B) Maintenance: maintaining the MatView data according to the p
Josh Berkus wrote:
I just worry about any feature which doesn't get as far as a
user-visible implementation. If someone doesn't do the rest of the
parts soon, such features tend to atrophy because nobody is using them.
While they're limited, there are complexly viable prototype quality
imp
> I don't want to see Materialized Views wander down the same path as
> partitioning, where lots of people produce "fun parts" patches, while
> ignoring the grunt work of things like production quality catalog
> support for the feature. I think Pavel's proposal got that part right
> by starting w
Josh Berkus wrote:
What would be the use case for (1) by itself?
There isn't any use case for just working on the infrastructure, just
like there's no use case for "Syntax for partitioning" on its own. That
why people rarely work on that part of these problems--it's boring and
produces n
Greg,
> I'm not saying someone can't jump right into (3), using the current
> implementations for (1) and (2) that are floating around out there. I
> just think it would end up wasting a fair amount of work on prototypes
> that don't work quite the same way as the eventual fully integrated
> vers
On Mon, Apr 12, 2010 at 3:43 PM, Greg Smith wrote:
> Josh Berkus wrote:
>>
>> There are basically 2 major parts for materialized views:
>> A) Planner: Getting the query planner to swap in the MatView for part of
>> a query automatically for query plan portions which the MatView supports;
>> B) Mai
Josh Berkus wrote:
There are basically 2 major parts for materialized views:
A) Planner: Getting the query planner to swap in the MatView for part of
a query automatically for query plan portions which the MatView supports;
B) Maintenance: maintaining the MatView data according to the programmed
On Mon, Apr 12, 2010 at 1:50 PM, Josh Berkus wrote:
> On 4/9/10 1:36 PM, pavelbaros wrote:
>> 2) change rewriter
>> - usually, view is relation with defined rule and when rewriting, rule
>> is fired and relation (view) is replaced by definition of view. If
>> relation do not have rule, planner and
On 4/9/10 1:36 PM, pavelbaros wrote:
> 2) change rewriter
> - usually, view is relation with defined rule and when rewriting, rule
> is fired and relation (view) is replaced by definition of view. If
> relation do not have rule, planner and executor behave to it as physical
> table (relation). In c
On Mon, Apr 12, 2010 at 2:16 AM, Pavel Stehule wrote:
> I am sure so
> dynamical materialised views is bad task for GSoC - it is too large,
> too complex. Manually refreshed views is adequate to two months work
> and it has sense.
That is my feeling also - though I fear that even the simplest
pos
2010/4/12 Robert Haas :
> On Sun, Apr 11, 2010 at 5:24 AM, Greg Smith wrote:
>> From the rest of your comments, I'm comfortable that you're in sync with the
>> not necessarily obvious risky spots here I wanted to raise awareness of.
>> It's unreasonable to expect we'll have exactly the same prior
Robert Haas wrote:
> On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
> wrote:
>> Robert Haas wrote:
>>> 2010/4/10 Andrew Dunstan :
Heikki Linnakangas wrote:
> 1. Keep the materialized view up-to-date when the base tables change.
> This can be further divided into many steps, you
On Sun, Apr 11, 2010 at 5:24 AM, Greg Smith wrote:
> From the rest of your comments, I'm comfortable that you're in sync with the
> not necessarily obvious risky spots here I wanted to raise awareness of.
> It's unreasonable to expect we'll have exactly the same priorities here,
> and I doubt it
On Sun, Apr 11, 2010 at 10:13 PM, Florian G. Pflug wrote:
> If continuous updates prove to be too hard initially, you could instead
> update the view on select if it's outdated. Such a materialized view
> would be a kind of inter-session cache for subselects.
>
> The hard part would probably be to
On 11.04.10 20:47 , Robert Haas wrote:
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
wrote:
Robert Haas wrote:
2010/4/10 Andrew Dunstan:
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables
change. This can be further divided into many steps, you ca
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> 2010/4/10 Andrew Dunstan :
>>> Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables change.
This can be further divided into many steps, you can begin by supporting
Robert Haas wrote:
> 2010/4/10 Andrew Dunstan :
>> Heikki Linnakangas wrote:
>>> 1. Keep the materialized view up-to-date when the base tables change.
>>> This can be further divided into many steps, you can begin by supporting
>>> automatic updates only on very simple views with e.g a single table
Robert Haas wrote:
I also think that you're underestimating the number of problems that
will have to be solved to get this done. It's going to take some
significant work - both design work and coding work - to figure out
how this should integrate into the rest of the system. (What should
be the
On Sat, Apr 10, 2010 at 11:40 PM, Greg Smith wrote:
> To be frank, that makes for a materalized view implementation of little
> value over what you can currently do as far as I'm concerned. It might be
> interesting as a prototype, but that's not necessarily going to look like
> what's needed to
Robert Haas wrote:
It's not obvious to me
that a brief full-table lock wouldn't be acceptable for an initial
implementation. Obviously it wouldn't be suitable for every use case
but since we're talking about manually refreshed views that was bound
to be true anyway.
There already is an init
Heikki Linnakangas wrote:
Your proposal basically describes
doing 1, in a limited fashion where the view is not updated
automatically, but only when the DBA runs a command to refresh it. I'm
not sure if that's useful enough on its own, writing "CREATE
MATERIALIZED VIEW ... SELECT ..." doesn't see
Greg Smith wrote:
> And work on MERGE support is itself blocked behind the fact that
> PostgreSQL doesn't have a good way to lock access to a key value
> that doesn't exist yet--what other databases call key range
> locking.
The bulk of the serializable implementation WIP is work to implement
2010/4/10 Andrew Dunstan :
> Heikki Linnakangas wrote:
>>
>> 1. Keep the materialized view up-to-date when the base tables change.
>> This can be further divided into many steps, you can begin by supporting
>> automatic updates only on very simple views with e.g a single table and
>> a where clause
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables change.
This can be further divided into many steps, you can begin by supporting
automatic updates only on very simple views with e.g a single table and
a where clause. Then extend that to support joins, ag
Greg Smith wrote:
> The main hidden complexity in this particular project relates to
> handling view refreshes. The non-obvious problem is that when the view
> updates, you need something like a SQL MERGE to really handle that in a
> robust way that doesn't conflict with concurrent access to queri
2010/4/9 Greg Smith :
> The main hidden complexity in this particular project relates to handling
> view refreshes. The non-obvious problem is that when the view updates, you
> need something like a SQL MERGE to really handle that in a robust way that
> doesn't conflict with concurrent access to q
pavelbaros wrote:
I am also waiting for approval for my repository named
"materialized_view" on git.postgresql.org, so I could publish
completed parts.
Presuming that you're going to wander there and get assigned what looks
like an official repo name for this project is a bit...optimistic.
1 - 100 of 103 matches
Mail list logo
