Re: [HACKERS] sequence data type

On 4/4/17, Peter Eisentraut wrote: > On 3/30/17 22:47, Vitaly Burovoy wrote: >> It seemed not very hard to fix it. >> Please find attached patch to be applied on top of your one. >> >> I've added more tests to cover different cases of changing bounds when >> data type is changed. > > Committed all

Re: [HACKERS] sequence data type

On 3/30/17 22:47, Vitaly Burovoy wrote: > It seemed not very hard to fix it. > Please find attached patch to be applied on top of your one. > > I've added more tests to cover different cases of changing bounds when > data type is changed. Committed all that. Thanks! -- Peter Eisentraut

Re: [HACKERS] sequence data type

On 3/30/17, Vitaly Burovoy wrote: > On 3/29/17, Vitaly Burovoy wrote: >> On 3/29/17, Michael Paquier wrote: >>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >>> wrote: I think min_value and max_value should not be set to "1" or "-1" but to real min/max of the type by default. >>>

Re: [HACKERS] sequence data type

On 3/30/17, Vitaly Burovoy wrote: > On 3/29/17, Vitaly Burovoy wrote: >> On 3/29/17, Michael Paquier wrote: >>> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >>> wrote: I think min_value and max_value should not be set to "1" or "-1" but to real min/max of the type by default. >>>

Re: [HACKERS] sequence data type

On 3/29/17, Vitaly Burovoy wrote: > On 3/29/17, Michael Paquier wrote: >> On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy >> wrote: >>> I think min_value and max_value should not be set to "1" or "-1" but >>> to real min/max of the type by default. >> >> This is the default behavior for ages, s

Re: [HACKERS] sequence data type

On 3/29/17, Michael Paquier wrote: > On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy > wrote: >> I think min_value and max_value should not be set to "1" or "-1" but >> to real min/max of the type by default. > > This is the default behavior for ages, since e8647c45 to be exact. So > you would c

Re: [HACKERS] sequence data type

On Thu, Mar 30, 2017 at 11:18 AM, Vitaly Burovoy wrote: > I think min_value and max_value should not be set to "1" or "-1" but > to real min/max of the type by default. This is the default behavior for ages, since e8647c45 to be exact. So you would change 20 years of history? -- Michael -- Se

Re: [HACKERS] sequence data type

On 3/29/17, Peter Eisentraut wrote: > Over at > > is is being discussed that maybe the behavior when altering the sequence > type isn't so great, because it currently doesn't update the min/m

Re: [HACKERS] sequence data type

On Thu, Mar 30, 2017 at 2:36 AM, Peter Eisentraut wrote: > Over at > > is is being discussed that maybe the behavior when altering the sequence > type isn't so great, because it currently doe

Re: [HACKERS] sequence data type

Over at is is being discussed that maybe the behavior when altering the sequence type isn't so great, because it currently doesn't update the min/max values of the sequence at all. So here is

Re: [HACKERS] sequence data type

On 2/1/17 10:01 PM, Michael Paquier wrote: > On Wed, Feb 1, 2017 at 10:02 AM, Michael Paquier > wrote: >> On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut >> wrote: >>> And here is a rebased patch for the original feature. I think this >>> addresses all raised concerns and suggestions now. >> >>

Re: [HACKERS] sequence data type

On Wed, Feb 1, 2017 at 10:02 AM, Michael Paquier wrote: > On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut > wrote: >> And here is a rebased patch for the original feature. I think this >> addresses all raised concerns and suggestions now. > > Thanks for the new version. That looks good to me af

Re: [HACKERS] sequence data type

On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut wrote: > And here is a rebased patch for the original feature. I think this > addresses all raised concerns and suggestions now. Thanks for the new version. That looks good to me after an extra lookup. -- Michael -- Sent via pgsql-hackers mail

Re: [HACKERS] sequence data type

And here is a rebased patch for the original feature. I think this addresses all raised concerns and suggestions now. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From ce2680ef072a9a4dc2cb879a70610d71ad24

Re: [HACKERS] sequence data type

On 1/30/17 12:42 AM, Michael Paquier wrote: > Sure. Thanks for looking into that and getting a patch out. Oh, I have > just noticed that sequence_1.out has been removed by 9c18104c. That's > nice. > Looking at the patch adding some new tests, the coverage really > increases (I did not run make cov

Re: [HACKERS] sequence data type

On Sat, Jan 28, 2017 at 2:49 AM, Peter Eisentraut wrote: > On 1/25/17 11:57 PM, Michael Paquier wrote: >> @@ -15984,6 +15992,9 @@ dumpSequence(Archive *fout, TableInfo *tbinfo) >> "CREATE SEQUENCE %s\n", >> fmtId(tbinfo->dobj.name)); >> >> + if (strcmp

Re: [HACKERS] sequence data type

On 1/25/17 11:57 PM, Michael Paquier wrote: > @@ -15984,6 +15992,9 @@ dumpSequence(Archive *fout, TableInfo *tbinfo) > "CREATE SEQUENCE %s\n", > fmtId(tbinfo->dobj.name)); > > + if (strcmp(seqtype, "bigint") != 0) > + appendPQExpBuffer(query, "

Re: [HACKERS] sequence data type

On Wed, Jan 25, 2017 at 11:53 PM, Peter Eisentraut wrote: > Here is an updated patch that allows changing the sequence type. This > was clearly a concern for reviewers, and the presented use cases seemed > convincing. I have been torturing this patch and it looks rather solid to me. Here are a c

Re: [HACKERS] sequence data type

Here is an updated patch that allows changing the sequence type. This was clearly a concern for reviewers, and the presented use cases seemed convincing. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From 5aff9

Re: [HACKERS] sequence data type

Peter Eisentraut wrote: > So in order to correctly answer the question, is the sequence about to > run out, you need to look not only at > the sequence but also any columns it is associated with. check_postgres > figures this out, but it's complicated and slow, and not easy to do > manual

Re: [HACKERS] sequence data type

Michael Paquier wrote: > Hm. Is symmetry an important properly for sequences? It seems to me > that if we map with the data types we had better use the MIN values > instead for consistency. So the concept of this patch is rather weird > and would introduce an exception with the rest of the

Re: [HACKERS] sequence data type

> "Daniel" == Daniel Verite writes: Daniel> Consider the case of a table with a SERIAL column which later Daniel> has to become a BIGINT due to growth. Currently a user would Daniel> just alter the column's type and does need to do anything with Daniel> the sequence. Daniel> With the p

Re: [HACKERS] sequence data type

Peter Eisentraut wrote: > This could probably be sorted out somehow, but I don't want > to be too lax now and cause problems for later features. There is a > similar case, namely changing the return type of a function, which we > also prohibit. Consider the case of a table with a SERIAL

Re: [HACKERS] sequence data type

On Tue, Jan 10, 2017 at 5:03 AM, Peter Eisentraut wrote: > On 1/8/17 2:39 PM, Steve Singer wrote: >> The only concern I have with the functionality is that there isn't a way >> to change the type of a sequence. > > If we implement the NEXT VALUE FOR expression (or anything similar that > returns a

Re: [HACKERS] sequence data type

On 1/8/17 2:39 PM, Steve Singer wrote: > The only concern I have with the functionality is that there isn't a way > to change the type of a sequence. If we implement the NEXT VALUE FOR expression (or anything similar that returns a value from the sequence), then the return type of that expression

Re: [HACKERS] sequence data type

On 12/31/2016 01:27 AM, Peter Eisentraut wrote: Another updated patch, with quite a bit of rebasing and some minor code polishing. Patch applies cleanly and the tests pass The feature seems to work as expected. I've tried this out and it behaves as expected and desired. I also tested the PG

Re: [HACKERS] sequence data type

On 9/8/16 4:06 PM, Peter Eisentraut wrote: > On 9/3/16 2:41 PM, Vik Fearing wrote: >> On 08/31/2016 06:22 AM, Peter Eisentraut wrote: >>> Here is a patch that adds the notion of a data type to a sequence. So >>> it might be CREATE SEQUENCE foo AS integer. The types are restricted to >>> int{2,4,8

Re: [HACKERS] sequence data type

On Tue, Nov 22, 2016 at 10:54 PM, Haribabu Kommi wrote: > Hi Vik and Vinayak, > > This is a gentle reminder. > > you both are assigned as reviewer's to the current patch in the 11-2016 > commitfest. > But you haven't shared your review yet. Please share your review about > the patch. This will he

Re: [HACKERS] sequence data type

Hi Vik and Vinayak, This is a gentle reminder. you both are assigned as reviewer's to the current patch in the 11-2016 commitfest. But you haven't shared your review yet. Please share your review about the patch. This will help us in smoother operation of commitfest. Please Ignore if you already

Re: [HACKERS] sequence data type

On Sun, Sep 11, 2016 at 12:38 PM, Vitaly Burovoy wrote: > On 9/10/16, Jim Nasby wrote: >> On 9/3/16 6:01 PM, Gavin Flower wrote: >>> I am curious as to the use cases for other possibilities. >> >> A hex or base64 type might be interesting, should those ever get created... >> -- >> Jim Nasby, Data

Re: [HACKERS] sequence data type

On 9/10/16, Jim Nasby wrote: > On 9/3/16 6:01 PM, Gavin Flower wrote: >> I am curious as to the use cases for other possibilities. > > A hex or base64 type might be interesting, should those ever get created... > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Hex or base64 are

Re: [HACKERS] sequence data type

On 9/3/16 6:01 PM, Gavin Flower wrote: I am curious as to the use cases for other possibilities. A hex or base64 type might be interesting, should those ever get created... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Dat

Re: [HACKERS] sequence data type

On 9/3/16 2:41 PM, Vik Fearing wrote: > On 08/31/2016 06:22 AM, Peter Eisentraut wrote: >> Here is a patch that adds the notion of a data type to a sequence. So >> it might be CREATE SEQUENCE foo AS integer. The types are restricted to >> int{2,4,8} as now. > > This patch does not apply cleanly

Re: [HACKERS] sequence data type

On 04/09/16 06:41, Vik Fearing wrote: On 08/31/2016 06:22 AM, Peter Eisentraut wrote: Here is a patch that adds the notion of a data type to a sequence. So it might be CREATE SEQUENCE foo AS integer. The types are restricted to int{2,4,8} as now. This patch does not apply cleanly to current m

Re: [HACKERS] sequence data type

On 08/31/2016 06:22 AM, Peter Eisentraut wrote: > Here is a patch that adds the notion of a data type to a sequence. So > it might be CREATE SEQUENCE foo AS integer. The types are restricted to > int{2,4,8} as now. This patch does not apply cleanly to current master (=600dc4c). -- Vik Fearing

[HACKERS] sequence data type

Here is a patch that adds the notion of a data type to a sequence. So it might be CREATE SEQUENCE foo AS integer. The types are restricted to int{2,4,8} as now. The main point of this is to make monitoring sequences less complicated. Right now, a serial column creates an int4 column but creates

Re: [HACKERS] Sequence Access Method WIP

On 04/04/16 15:53, Fabrízio de Royes Mello wrote: On Thu, Mar 31, 2016 at 9:19 AM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: > > Hi, > > new version attached that should fix the issue. It was alignment - honestly don't know what I was thinking using fixed alignment when the AMs can

Re: [HACKERS] Sequence Access Method WIP

Hi, Thanks for review. On 30/03/16 15:22, Jose Luis Tallon wrote: [Partial review] Evaluated: 0002-gapless-seq-2016-03-29-2.patch Needs updating code copyright years ... or is this really from 2013? [ contrib/gapless_seq/gapless_seq.c ] Patch applies cleanly to current master (3063e7a84026ced

Re: [HACKERS] Sequence Access Method WIP

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 [Partial review] Evaluated: 0002-gapless-seq-2016-03-29-2.patch Needs updatin

Re: [HACKERS] Sequence Access Method WIP

On Tue, Mar 29, 2016 at 5:58 PM, Petr Jelinek wrote: > > On 29/03/16 22:08, Fabrízio de Royes Mello wrote: >> >> >> >> On Tue, Mar 29, 2016 at 4:59 PM, Petr Jelinek > > wrote: >> > >> > On 29/03/16 19:46, Fabrízio de Royes Mello wrotez >> >> >> >> >> >> > >> >>

Re: [HACKERS] Sequence Access Method WIP

On 29/03/16 22:08, Fabrízio de Royes Mello wrote: On Tue, Mar 29, 2016 at 4:59 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: > > On 29/03/16 19:46, Fabrízio de Royes Mello wrotez >> >> >> > >> > Hmm I am unable to reproduce this. What OS? Any special configure >> flags you use?

Re: [HACKERS] Sequence Access Method WIP

On Tue, Mar 29, 2016 at 4:59 PM, Petr Jelinek wrote: > > On 29/03/16 19:46, Fabrízio de Royes Mello wrotez >> >> >> > >> > Hmm I am unable to reproduce this. What OS? Any special configure >> flags you use? >> > >> >> In my environment the error remains with your last patches. >> >> I didn't us

Re: [HACKERS] Sequence Access Method WIP

On 29/03/16 19:46, Fabrízio de Royes Mello wrotez > > Hmm I am unable to reproduce this. What OS? Any special configure flags you use? > In my environment the error remains with your last patches. I didn't use any special. ./configure --prefix=/home/fabrizio/pgsql --enable-cassert --enable

Re: [HACKERS] Sequence Access Method WIP

On Tue, Mar 29, 2016 at 2:26 PM, Petr Jelinek wrote: > > On 29/03/16 18:50, Fabrízio de Royes Mello wrote: >> >> >> >> On Tue, Mar 29, 2016 at 12:25 PM, David Steele > > wrote: >> > >> > Hi Petr, >> > >> > On 3/28/16 3:11 PM, Fabrízio de Royes Mello wrote: >> > >>

Re: [HACKERS] Sequence Access Method WIP

Hi Petr, On 3/28/16 3:11 PM, Fabrízio de Royes Mello wrote: fabrizio@bagual:~/pgsql $ bin/pg_dump > /tmp/fabrizio.sql pg_dump: [archiver (db)] query failed: ERROR: column "sequence_name" does not exist LINE 1: SELECT sequence_name, start_value, increment_by, CASE WHEN i... ^ pg

Re: [HACKERS] Sequence Access Method WIP

On Thu, Mar 24, 2016 at 6:12 PM, Petr Jelinek wrote: > > Hi, > > I rebased this on top of the recently committed CREATE ACCESS METHOD. > Hi, I got the above error trying to apply to the current master: $ git apply /home/fabrizio/Downloads/0001-seqam-2016-03-24.patch error: patch failed: src/bac

Re: [HACKERS] Sequence Access Method WIP

On 19/03/16 23:02, Alvaro Herrera wrote: Petr Jelinek wrote: And finally the 0003-gapless-seq is example contrib module that implements dependably and transitionally safe gapless sequence access method. It's obviously slow as it has to do locking and basically serialize all the changes to seque

Re: [HACKERS] Sequence Access Method WIP

On 3/4/16 11:09 PM, Petr Jelinek wrote: > But first here is updated patch for sequence access methods. I went with > the previously discussed custom type as this gives us proper control > over the width of the state and making sure that it's not gonna be > toastable, etc and we need this as sequen

Re: [HACKERS] Sequence Access Method WIP

Petr Jelinek wrote: > And finally the 0003-gapless-seq is example contrib module that implements > dependably and transitionally safe gapless sequence access method. It's > obviously slow as it has to do locking and basically serialize all the > changes to sequence so only one transaction may use

Re: [HACKERS] Sequence Access Method WIP

On Sat, Jan 30, 2016 at 3:37 PM, Petr Jelinek wrote: > On 29 January 2016 at 23:59, Robert Haas wrote: > > On Fri, Jan 29, 2016 at 5:24 PM, Tom Lane wrote: > >> Alexander Korotkov writes: > >>> On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > >>> wrote: > I'

Re: [HACKERS] Sequence Access Method WIP

On 30 January 2016 at 13:48, Robert Haas wrote: > On Sat, Jan 30, 2016 at 7:37 AM, Petr Jelinek wrote: >> Just as a note, CREATE SEQUENCE ACCESS METHOD already causes grammar >> conflict now, that's why my proposal was different, I didn't want to >> add more keywords. I think Alvaro's proposal is

Re: [HACKERS] Sequence Access Method WIP

On Sat, Jan 30, 2016 at 7:37 AM, Petr Jelinek wrote: > Just as a note, CREATE SEQUENCE ACCESS METHOD already causes grammar > conflict now, that's why my proposal was different, I didn't want to > add more keywords. I think Alvaro's proposal is fine as well. I missed your proposal, I guess, so pl

Re: [HACKERS] Sequence Access Method WIP

On 29 January 2016 at 23:59, Robert Haas wrote: > On Fri, Jan 29, 2016 at 5:24 PM, Tom Lane wrote: >> Alexander Korotkov writes: >>> On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera >>> wrote: I'm thinking we'd do CREATE ACCESS METHOD foobar TYPE INDEX or something like that. >> >>> I

Re: [HACKERS] Sequence Access Method WIP

On Fri, Jan 29, 2016 at 5:24 PM, Tom Lane wrote: > Alexander Korotkov writes: >> On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera >> wrote: >>> I'm thinking we'd do CREATE ACCESS METHOD foobar TYPE INDEX or something >>> like that. > >> I would prefer "CREATE {INDEX | SEQUENCE | ... } ACCESS METH

Re: [HACKERS] Sequence Access Method WIP

Alexander Korotkov writes: > On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera > wrote: >> I'm thinking we'd do CREATE ACCESS METHOD foobar TYPE INDEX or something >> like that. > I would prefer "CREATE {INDEX | SEQUENCE | ... } ACCESS METHOD name HANDLER > handler;", but I don't insist. I think

Re: [HACKERS] Sequence Access Method WIP

On Fri, Jan 29, 2016 at 6:36 PM, Alvaro Herrera wrote: > Petr Jelinek wrote: > > On 29 January 2016 at 14:48, Tom Lane wrote: > > > Alvaro Herrera writes: > > > > Uh, what? Surely we would provide a bespoke command for each possible > > > sort of handler. As an example, CREATE INDEX ACCESS ME

Re: [HACKERS] Sequence Access Method WIP

Alvaro Herrera writes: >> On 29 January 2016 at 14:48, Tom Lane wrote: > Uh, what? Surely we would provide a bespoke command for each possible > sort of handler. As an example, CREATE INDEX ACCESS METHOD ought to check > that the provided function has the right signature, and then it would put

Re: [HACKERS] Sequence Access Method WIP

Petr Jelinek wrote: > On 29 January 2016 at 14:48, Tom Lane wrote: > > Alvaro Herrera writes: > > Uh, what? Surely we would provide a bespoke command for each possible > > sort of handler. As an example, CREATE INDEX ACCESS METHOD ought to check > > that the provided function has the right sig

Re: [HACKERS] Sequence Access Method WIP

On 29 January 2016 at 14:48, Tom Lane wrote: > Alvaro Herrera writes: >> I would guess that the DDL boilterplate should come from Alexander >> Korotkov's patch, right? I think a first easy step may be to combine >> parts both patches so that we get the "amkind" column from this patch >> and the

Re: [HACKERS] Sequence Access Method WIP

Alvaro Herrera writes: > I would guess that the DDL boilterplate should come from Alexander > Korotkov's patch, right? I think a first easy step may be to combine > parts both patches so that we get the "amkind" column from this patch > and the DDL support from Alexander's patch (means that his p

Re: [HACKERS] Sequence Access Method WIP

Petr Jelinek wrote: > On 18 January 2016 at 09:19, Craig Ringer wrote: > > Needs rework after the commit of https://commitfest.postgresql.org/8/336/ > > Here is version that applies to current master. There is some work to > do (mostly cleanup) and the DDL is missing, but that's because I want >

Re: [HACKERS] Sequence Access Method WIP

Needs rework after the commit of https://commitfest.postgresql.org/8/336/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Sequence Access Method WIP

On 1 January 2016 at 07:51, Petr Jelinek wrote: > > Other than that, this is based on the new am api by Alexander Korotkov > [1]. It extends it by adding another column called amkind to the pg_am > which can have either value "i" for index or "S" for sequence (same as > relkind in pg_class for th

Re: [HACKERS] Sequence Access Method WIP

On 2015-09-16 13:21, Thom Brown wrote: On 28 July 2015 at 19:51, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: On 2015-07-28 20:11, Heikki Linnakangas wrote: Petr, is this enough feedback on this patch for this commitfest, or are there some other issues you want

Re: [HACKERS] Sequence Access Method WIP

On 28 July 2015 at 19:51, Petr Jelinek wrote: > On 2015-07-28 20:11, Heikki Linnakangas wrote: > >> >> Petr, is this enough feedback on this patch for this commitfest, or are >> there some other issues you want to discuss before I mark this as >> returned? >> >> > You can mark it as returned, I d

Re: [HACKERS] Sequence Access Method WIP

On 2015-07-28 20:11, Heikki Linnakangas wrote: Petr, is this enough feedback on this patch for this commitfest, or are there some other issues you want to discuss before I mark this as returned? You can mark it as returned, I didn't have much time to actually do much useful work on this in t

Re: [HACKERS] Sequence Access Method WIP

So, we have this patch in the commitfest again. Let's see where we are, and try to find a consensus on what needs to be done before this can be committed. On 06/17/2015 06:51 PM, Petr Jelinek wrote: On 2015-06-15 11:32, Vik Fearing wrote: I've been looking at these patches a bit and here are

Re: [HACKERS] Sequence Access Method WIP

On 2015-06-15 11:32, Vik Fearing wrote: I've been looking at these patches a bit and here are some comments: Thanks for looking at this. Patch 1: seqam I would like to see an example in the docs for CREATE SEQUENCE. That's perhaps not possible (or desirable) with only the "local" seqam? N

Re: [HACKERS] Sequence Access Method WIP

I've been looking at these patches a bit and here are some comments: Patch 1: seqam I would like to see an example in the docs for CREATE SEQUENCE. That's perhaps not possible (or desirable) with only the "local" seqam? Not sure. In the docs for pg_class, there is no mention that relam refers

Re: [HACKERS] Sequence Access Method WIP

On 13/05/15 14:15, Heikki Linnakangas wrote: I don't see what calamity will occur if we commit this. If you don't want a sequence AM, don't ever use this. I'd like the API to be good for its purpose. Also, I did mention that the the current patch makes the situation slightly worse for people wh

Re: [HACKERS] Sequence Access Method WIP

On 05/13/2015 02:12 PM, Simon Riggs wrote: This has had around 2 years of thought at this point. I don't agree it needs more thought. Noted. There is one clear use case for this and it is of benefit to many distributed architectures. Right. What's your point? I don't see what calamity wil

Re: [HACKERS] Sequence Access Method WIP

On 13/05/15 12:56, Heikki Linnakangas wrote: On 05/13/2015 07:10 AM, Alvaro Herrera wrote: Heikki, do you have time to go through this at this point? I'm afraid I won't :-(. I did intend to, but looking at the calendar, I won't have the time to review this thoroughly enough to commit. Sorry.

Re: [HACKERS] Sequence Access Method WIP

On 13 May 2015 at 11:56, Heikki Linnakangas wrote: > On 05/13/2015 07:10 AM, Alvaro Herrera wrote: > >> Heikki, do you have time to go through this at this point? >> > > I'm afraid I won't :-(. I did intend to, but looking at the calendar, I > won't have the time to review this thoroughly enough

Re: [HACKERS] Sequence Access Method WIP

On 05/13/2015 07:10 AM, Alvaro Herrera wrote: Heikki, do you have time to go through this at this point? I'm afraid I won't :-(. I did intend to, but looking at the calendar, I won't have the time to review this thoroughly enough to commit. Sorry. I haven't looked at the CREATE/DROP ACCESS M

Re: [HACKERS] Sequence Access Method WIP

On 20/04/15 17:50, Heikki Linnakangas wrote: On 03/15/2015 09:07 PM, Petr Jelinek wrote: Slightly updated version of the patch. Mainly rebased against current master (there were several conflicts) and fixed some typos, no real functional change. I also attached initial version of the API sgml

Re: [HACKERS] Sequence Access Method WIP

Heikki Linnakangas wrote: > * The transformations of the arrays in get_state() and set_state() functions > are a bit complicated. The seqam_get_state() function returns two C arrays, > and pg_sequence_get_state() turns them into a text[] array. Why not > construct the text[] array directly in the

Re: [HACKERS] Sequence Access Method WIP

On 20/04/15 12:05, Andres Freund wrote: On 2015-04-20 12:49:39 +0300, Heikki Linnakangas wrote: With the patch, pg_class.relam column references to the pg_seqam table for sequences, but pg_indexam for indexes. I believe it's the first instance where we reuse a "foreign key" column like that. It'

Re: [HACKERS] Sequence Access Method WIP

On 2015-04-20 12:49:39 +0300, Heikki Linnakangas wrote: > With the patch, pg_class.relam column references to the pg_seqam table for > sequences, but pg_indexam for indexes. I believe it's the first instance > where we reuse a "foreign key" column like that. It's not a real foreign > key, of course

Re: [HACKERS] Sequence Access Method WIP

On 03/15/2015 09:07 PM, Petr Jelinek wrote: Slightly updated version of the patch. Mainly rebased against current master (there were several conflicts) and fixed some typos, no real functional change. I also attached initial version of the API sgml doc. Thanks! With the patch, pg_class.relam

Re: [HACKERS] Sequence Access Method WIP

On 18/02/15 02:59, Petr Jelinek wrote: On 17/02/15 23:11, Robert Haas wrote: On Sun, Feb 15, 2015 at 1:40 PM, Petr Jelinek wrote: sending new version that is updated along the lines of what we discussed at FOSDEM, which means: - back to single bytea amdata column (no custom columns) Well,

Re: [HACKERS] Sequence Access Method WIP

On 17/02/15 23:11, Robert Haas wrote: On Sun, Feb 15, 2015 at 1:40 PM, Petr Jelinek wrote: sending new version that is updated along the lines of what we discussed at FOSDEM, which means: - back to single bytea amdata column (no custom columns) Well, the main argument is still future possi

Re: [HACKERS] Sequence Access Method WIP

On Sun, Feb 15, 2015 at 1:40 PM, Petr Jelinek wrote: > sending new version that is updated along the lines of what we discussed at > FOSDEM, which means: > > - back to single bytea amdata column (no custom columns) Why? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Pos

Re: [HACKERS] Sequence Access Method WIP

On 28/01/15 18:09, Heikki Linnakangas wrote: On 01/23/2015 02:34 AM, Petr Jelinek wrote: On 22/01/15 17:02, Petr Jelinek wrote: The new version (the one that is not submitted yet) of gapless sequence is way more ugly and probably not best example either but does guarantee gaplessness (it store

Re: [HACKERS] Sequence Access Method WIP

On 01/23/2015 02:34 AM, Petr Jelinek wrote: On 22/01/15 17:02, Petr Jelinek wrote: The new version (the one that is not submitted yet) of gapless sequence is way more ugly and probably not best example either but does guarantee gaplessness (it stores the last value in it's own value table). So

Re: [HACKERS] Sequence Access Method WIP

On 22/01/15 16:50, Heikki Linnakangas wrote: On 01/12/2015 11:33 PM, Petr Jelinek wrote: Second patch adds DDL support. I originally wanted to make it CREATE/DROP SEQUENCE ACCESS METHOD... but that would mean making ACCESS a reserver keyword so I went for CREATE ACCESS METHOD FOR SEQUENCES which

Re: [HACKERS] Sequence Access Method WIP

On Thu, Jan 22, 2015 at 10:50 AM, Heikki Linnakangas wrote: > On 01/12/2015 11:33 PM, Petr Jelinek wrote: >> Second patch adds DDL support. I originally wanted to make it >> CREATE/DROP SEQUENCE ACCESS METHOD... but that would mean making ACCESS >> a reserver keyword so I went for CREATE ACCESS ME

Re: [HACKERS] Sequence Access Method WIP

On 01/12/2015 11:33 PM, Petr Jelinek wrote: Second patch adds DDL support. I originally wanted to make it CREATE/DROP SEQUENCE ACCESS METHOD... but that would mean making ACCESS a reserver keyword so I went for CREATE ACCESS METHOD FOR SEQUENCES which does not need to change anything (besides add

Re: [HACKERS] Sequence Access Method WIP

On 13/01/15 13:24, Tomas Vondra wrote: On 12.1.2015 22:33, Petr Jelinek wrote: On 15/12/14 11:36, Petr Jelinek wrote: On 10/12/14 03:33, Petr Jelinek wrote: On 24/11/14 12:16, Heikki Linnakangas wrote: About the rough edges: - The AlterSequence is not prettiest code around as we now have to c

Re: [HACKERS] Sequence Access Method WIP

On 12.1.2015 22:33, Petr Jelinek wrote: > On 15/12/14 11:36, Petr Jelinek wrote: >> On 10/12/14 03:33, Petr Jelinek wrote: >>> On 24/11/14 12:16, Heikki Linnakangas wrote: >>> >>> About the rough edges: >>> - The AlterSequence is not prettiest code around as we now have to >>> create new relation w

Re: [HACKERS] Sequence Access Method WIP

On 10/12/14 03:33, Petr Jelinek wrote: On 24/11/14 12:16, Heikki Linnakangas wrote: About the rough edges: - The AlterSequence is not prettiest code around as we now have to create new relation when sequence AM is changed and I don't know how to do that nicely - I am not sure if I did the lockin

Re: [HACKERS] Sequence Access Method WIP

> >>May I possibly suggest a file-per-schema model instead? This approach would > >>certainly solve the excessive i-node consumption problem that --I guess-- > >>Andres is trying to address here. > >I don't think that really has any advantages. > > Just spreading the I/O load, nothing more, it see

Re: [HACKERS] Sequence Access Method WIP

On 12/3/14, 8:50 AM, José Luis Tallón wrote: May I possibly suggest a file-per-schema model instead? This approach would certainly solve the excessive i-node consumption problem that --I guess-- Andres is trying to address here. I don't think that really has any advantages. Just spreading th

Re: [HACKERS] Sequence Access Method WIP

On 12/03/2014 11:24 AM, Andres Freund wrote: On 2014-12-03 10:59:50 +0100, José Luis Tallón wrote: snip] I don't think the WAL logging would need to change much in comparison to the current solution. We'd just add the page number to the WAL record. The biggest advantage would be to require few

Re: [HACKERS] Sequence Access Method WIP

On 02/12/14 20:21, Andres Freund wrote: On 2014-11-24 13:16:24 +0200, Heikki Linnakangas wrote: To be clear: I don't think this API is very good for its stated purpose, for implementing global sequences for use in a cluster. For the reasons I've mentioned before. I'd like to see two changes to

Re: [HACKERS] Sequence Access Method WIP

On 2014-12-03 10:59:50 +0100, José Luis Tallón wrote: > On 12/02/2014 08:21 PM, Andres Freund wrote: > >[snip] > >>2. Instead of the single amdata field, make it possible for the > >>implementation to define any number of fields with any datatype in the > >>tuple. That would make debugging, monitor

Re: [HACKERS] Sequence Access Method WIP

On 12/02/2014 08:21 PM, Andres Freund wrote: [snip] 2. Instead of the single amdata field, make it possible for the implementation to define any number of fields with any datatype in the tuple. That would make debugging, monitoring etc. easier. My main problem with that approach is that it pret

Re: [HACKERS] Sequence Access Method WIP

On 2014-11-24 13:16:24 +0200, Heikki Linnakangas wrote: > To be clear: I don't think this API is very good for its stated purpose, for > implementing global sequences for use in a cluster. For the reasons I've > mentioned before. I'd like to see two changes to this proposal: > > 1. Make the AM im

Re: [HACKERS] Sequence Access Method WIP

On 11/08/2014 04:21 PM, Simon Riggs wrote: On 5 November 2014 17:32, Heikki Linnakangas wrote: Why does sequence_alloc need the current value? If it's a "remote" seqam, the current value is kept in the remote server, and the last value that was given to this PostgreSQL server is irrelevant. T

Re: [HACKERS] Sequence Access Method WIP

On 09/11/14 20:47, Heikki Linnakangas wrote: On 11/08/2014 01:57 AM, Petr Jelinek wrote: My main problem is actually not with having tuple per-seqAM, but more with the fact that Heikki does not want to have last_value as compulsory column/parameter. How is the new AM then supposed to know where

Re: [HACKERS] Sequence Access Method WIP

On 11/08/2014 01:57 AM, Petr Jelinek wrote: My main problem is actually not with having tuple per-seqAM, but more with the fact that Heikki does not want to have last_value as compulsory column/parameter. How is the new AM then supposed to know where to pick up and if it even can pick up? Call

  1   2   >