logical column ordering
So I've been updating my very old patch to allow logical and physical
column reordering. Here's a WIP first cut for examination. There are
plenty of rough edges here; most importantly there is no UI at all for
column reordering other than direct UPDATEs of pg_attribute, which most
likely falls afoul of cache invalidation problems. For now I'm focusing
on correct processing when columns are moved logically; I haven't yet
started to see how to move columns physically, but I think that part is
much more localized than the logical one.
Just as a reminder, this effort is an implementation of ideas that have
been discussed previously; in particular, see these threads:
/messages/by-id/20414.1166719407@sss.pgh.pa.us (2006)
/messages/by-id/6843.1172126270@sss.pgh.pa.us (2007)
/messages/by-id/23035.1227659434@sss.pgh.pa.us (2008)
To recap, this is based on the idea of having three numbers for each
attribute rather than a single attnum; the first of these is attnum (a
number that uniquely identifies an attribute since its inception and may
or may not have any relationship to its storage position and the place
it expands to through user interaction). The second is attphysnum,
which indicates where it is stored in the physical structure. The third
is attlognum, which indicates where it expands in "*", where must its
values be placed in COPY or VALUES lists, etc --- the logical position
as the user sees it.
The first thing where this matters is tuple descriptor expansion in
parse analysis; at this stage, things such as "*" (in "select *") are
turned into a target list, which must be sorted according to attlognum.
To achieve this I added a new routine to tupledescs,
TupleDescGetSortedAttrs() which computes a new Attribute array and
caches it in the TupleDesc for later uses; this array points to the
same elements in the normal attribute list but is order by attlognum.
Additionally there are a number of places that iterate on such target
lists and use the iterator as the attribute number; those were modified
to have a separate attribute number as attnum within the loop.
Another place that needs tweaking is heapam.c, which must construct a
physical tuple from Datum/nulls arrays (heap_form_tuple). In some cases
the input arrays are sorted in logical column order. I have opted to
add a flag that indicates whether the array is in logical order; if it
is the routines compute the correct physical order. (Actually as I
mentioned above I still haven't made any effort to make sure they work
in the case that attnum differs from attphysnum, but this should be
reasonably contained changes.)
The part where I stopped just before sending the current state is this
error message:
alvherre=# select * from quux where (a,c) in ( select a,c from quux );
select * from quux where (a,c) in ( select a,c from quux );
ERROR: failed to find unique expression in subplan tlist
I'm going to see about it while I get feedback on the rest of this patch; in
particular, extra test cases that fail to work when columns have been
moved around are welcome, so that I can add them to the regress test.
What I have now is the basics I'm building as I go along. The
regression tests show examples of some logical column renumbering (which
can be done after the table already contains some data) but none of
physical column renumbering (which can only be done when the table is
completely empty.) My hunch is that the sample foo, bar, baz, quux
tables should present plenty of opportunities to display brokenness in
the planner and executor.
PS: Phil Currier allegedly had a patch back in 2007-2008 that did this,
or something very similar ... though he never posted a single bit of it,
and then he vanished without a trace. If he's still available it would
be nice to see his WIP patch, even if outdated, as it might serve as
inspiration and let us know what other places need tweaking.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
columns-logical.patchtext/x-diff; charset=us-asciiDownload+875-186
On 12/9/14, 11:41 AM, Alvaro Herrera wrote:
I'm going to see about it while I get feedback on the rest of this patch; in
particular, extra test cases that fail to work when columns have been
moved around are welcome, so that I can add them to the regress test.
What I have now is the basics I'm building as I go along. The
regression tests show examples of some logical column renumbering (which
can be done after the table already contains some data) but none of
physical column renumbering (which can only be done when the table is
completely empty.) My hunch is that the sample foo, bar, baz, quux
tables should present plenty of opportunities to display brokenness in
the planner and executor.
The ideal case would be to do something like randomizing logical and physical ordering as tables are created throughout the entire test suite (presumably as an option). That should work for physical ordering, but presumably it would pointlessly blow up on logical ordering because the expected output is hard-coded.
Perhaps instead of randomizing logical ordering we could force that to be the same ordering in which fields were supplied and actually randomize attnum?
In particular, I'm thinking that in DefineRelation we can randomize stmt->tableElts before merging in inheritance attributes.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/09/2014 09:41 AM, Alvaro Herrera wrote:
The first thing where this matters is tuple descriptor expansion in
parse analysis; at this stage, things such as "*" (in "select *") are
turned into a target list, which must be sorted according to attlognum.
To achieve this I added a new routine to tupledescs,
The two other major cases are:
INSERT INTO table SELECT|VALUES ...
COPY table FROM|TO ...
... although copy should just be a subclass of SELECT.
Question on COPY, though: there's reasons why people would want COPY to
dump in either physical or logical order. If you're doing COPY to
create CSV files for output, then you want the columns in logical order.
If you're doing COPY for pg_dump, then you want them in physical order
for faster dump/reload. So we're almost certainly going to need to have
an option for COPY.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMbabec396840f3be2f40e87e9027a4e1754b12e210fc191725f6e523c73786e77a40d4dafbdb2c095d7d0b52675464e8f@asav-1.01.com
On 12/09/2014 06:19 PM, Josh Berkus wrote:
On 12/09/2014 09:41 AM, Alvaro Herrera wrote:
The first thing where this matters is tuple descriptor expansion in
parse analysis; at this stage, things such as "*" (in "select *") are
turned into a target list, which must be sorted according to attlognum.
To achieve this I added a new routine to tupledescs,The two other major cases are:
INSERT INTO table SELECT|VALUES ...
COPY table FROM|TO ...
... although copy should just be a subclass of SELECT.
Question on COPY, though: there's reasons why people would want COPY to
dump in either physical or logical order. If you're doing COPY to
create CSV files for output, then you want the columns in logical order.
If you're doing COPY for pg_dump, then you want them in physical order
for faster dump/reload. So we're almost certainly going to need to have
an option for COPY.
I seriously doubt it, although I could be wrong. Unless someone can show
a significant performance gain from using physical order, which would be
a bit of a surprise to me, I would just stick with logical ordering as
the default.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan wrote:
On 12/09/2014 06:19 PM, Josh Berkus wrote:
On 12/09/2014 09:41 AM, Alvaro Herrera wrote:
The first thing where this matters is tuple descriptor expansion in
parse analysis; at this stage, things such as "*" (in "select *") are
turned into a target list, which must be sorted according to attlognum.
To achieve this I added a new routine to tupledescs,The two other major cases are:
INSERT INTO table SELECT|VALUES ...
COPY table FROM|TO ...
Yes, both are covered.
... although copy should just be a subclass of SELECT.
It is not. There's one part of COPY that goes through SELECT
processing, but only when the "table" being copied is a subselect.
Normal COPY does not use the same code path.
Question on COPY, though: there's reasons why people would want COPY to
dump in either physical or logical order. If you're doing COPY to
create CSV files for output, then you want the columns in logical order.
If you're doing COPY for pg_dump, then you want them in physical order
for faster dump/reload. So we're almost certainly going to need to have
an option for COPY.I seriously doubt it, although I could be wrong. Unless someone can show a
significant performance gain from using physical order, which would be a bit
of a surprise to me, I would just stick with logical ordering as the
default.
Well, we have an optimization that avoids a projection step IIRC by
using the "physical tlist" instead of having to build a tailored one. I
guess the reason that's there is because somebody did measure an
improvement. Maybe it *is* worth having as an option for pg_dump ...
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
Question on COPY, though: there's reasons why people would want COPY to
dump in either physical or logical order. If you're doing COPY to
create CSV files for output, then you want the columns in logical order.
If you're doing COPY for pg_dump, then you want them in physical order
for faster dump/reload. So we're almost certainly going to need to have
an option for COPY.
This is complete nonsense, Josh, or at least it is until you can provide
some solid evidence to believe that column ordering would make any
noticeable performance difference in COPY. I know of no reason to believe
that the existing user-defined-column-ordering option makes any difference.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Andrew Dunstan wrote:
I seriously doubt it, although I could be wrong. Unless someone can show a
significant performance gain from using physical order, which would be a bit
of a surprise to me, I would just stick with logical ordering as the
default.
Well, we have an optimization that avoids a projection step IIRC by
using the "physical tlist" instead of having to build a tailored one. I
guess the reason that's there is because somebody did measure an
improvement. Maybe it *is* worth having as an option for pg_dump ...
The physical tlist thing is there because it's demonstrable that
ExecProject() takes nonzero time. COPY does not go through ExecProject
though. What's more, it already has code to deal with a user-specified
column order, and nobody's ever claimed that that code imposes a
measurable performance overhead.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Dec 10, 2014 at 12:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Andrew Dunstan wrote:
I seriously doubt it, although I could be wrong. Unless someone can show a
significant performance gain from using physical order, which would be a bit
of a surprise to me, I would just stick with logical ordering as the
default.Well, we have an optimization that avoids a projection step IIRC by
using the "physical tlist" instead of having to build a tailored one. I
guess the reason that's there is because somebody did measure an
improvement. Maybe it *is* worth having as an option for pg_dump ...The physical tlist thing is there because it's demonstrable that
ExecProject() takes nonzero time. COPY does not go through ExecProject
though. What's more, it already has code to deal with a user-specified
column order, and nobody's ever claimed that that code imposes a
measurable performance overhead.
Also, if we're adding options to use the physical rather than the
logical column ordering in too many places, that's probably a sign
that we need to rethink this whole concept. The concept of a logical
column ordering doesn't have much meaning if you're constantly forced
to fall back to some other column ordering whenever you want good
performance.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Wed, Dec 10, 2014 at 12:17 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Andrew Dunstan wrote:
I seriously doubt it, although I could be wrong. Unless someone can show a
significant performance gain from using physical order, which would be a bit
of a surprise to me, I would just stick with logical ordering as the
default.Well, we have an optimization that avoids a projection step IIRC by
using the "physical tlist" instead of having to build a tailored one. I
guess the reason that's there is because somebody did measure an
improvement. Maybe it *is* worth having as an option for pg_dump ...The physical tlist thing is there because it's demonstrable that
ExecProject() takes nonzero time. COPY does not go through ExecProject
though. What's more, it already has code to deal with a user-specified
column order, and nobody's ever claimed that that code imposes a
measurable performance overhead.Also, if we're adding options to use the physical rather than the
logical column ordering in too many places, that's probably a sign
that we need to rethink this whole concept. The concept of a logical
column ordering doesn't have much meaning if you're constantly forced
to fall back to some other column ordering whenever you want good
performance.
FWIW I have no intention to add options for physical/logical ordering
anywhere. All users will see is that tables will follow the same
(logical) order everywhere.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Dec 10, 2014 at 9:25 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
FWIW I have no intention to add options for physical/logical ordering
anywhere. All users will see is that tables will follow the same
(logical) order everywhere.
Just to be clear, I wasn't in any way attending to say that the patch
had a problem in this area. I was just expressing concern about the
apparent rush to judgement on whether converting between physical and
logical column ordering would be expensive. I certainly think that's
something that we should test - for example, we might want to consider
whether there are cases where you could maybe convince the executor to
spend a lot of time pointlessly reorganizing tuples in ways that
wouldn't happen today. But I have no particular reason to think that
any issues we hit there issues won't be solvable.
To the extent that I have any concern about the patch at this point,
it's around stability. I would awfully rather see something like this
get committed at the beginning of a development cycle than the end.
It's quite possible that I'm being more nervous than is justified, but
given that we're *still* fixing bugs related to dropped-column
handling (cf. 9b35ddce93a2ef336498baa15581b9d10f01db9c from July of
this year) which was added in July 2002, maybe not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert, all,
* Robert Haas (robertmhaas@gmail.com) wrote:
To the extent that I have any concern about the patch at this point,
it's around stability. I would awfully rather see something like this
get committed at the beginning of a development cycle than the end.
I tend to agree with this; we have a pretty bad habit of bouncing
around big patches until the end and then committing them. That's not
as bad when the patch has been getting reviews and feedback over a few
months (or years) but this particular patch isn't even code-complete at
this point, aiui.
It's quite possible that I'm being more nervous than is justified, but
given that we're *still* fixing bugs related to dropped-column
handling (cf. 9b35ddce93a2ef336498baa15581b9d10f01db9c from July of
this year) which was added in July 2002, maybe not.
I'm not quite sure that I see how that's relevant. Bugs will happen,
unfortunately, no matter how much review is done of a given patch. That
isn't to say that we shouldn't do any review, but it's a trade-off.
This change, at least, strikes me as less likely to have subtle bugs
in it as compared to the dropped column case.
Thanks,
Stephen
On Wed, Dec 10, 2014 at 11:22 AM, Stephen Frost <sfrost@snowman.net> wrote:
I'm not quite sure that I see how that's relevant. Bugs will happen,
unfortunately, no matter how much review is done of a given patch. That
isn't to say that we shouldn't do any review, but it's a trade-off.
This change, at least, strikes me as less likely to have subtle bugs
in it as compared to the dropped column case.
Yeah, that's possible. They seem similar to me because they both
introduce new ways for the tuple as it is stored on disk to be
different from what must be shown to the user. But I don't really
know how well that translates to what needs to be changed on a code
level. If we're basically going back over all the same places that
needed special handling for attisdropped, then the likelihood of bugs
may be quite a bit lower than it was for that patch, because now we
know (mostly!) which places require attisdropped handling and we can
audit them all to make sure they handle this, too. But if it's a
completely different set of places that need to be touched, then I
think there's a lively possibility for bugs of omission.
Ultimately, I think this is mostly going to be a question of what
Alvaro feels comfortable with; he's presumably going to have a better
sense of where and to what extent there might be bugs lurking than any
of the rest of us. But the point is worth considering, because I
think we would probably all agree that having a release that is stable
and usable right out of the gate is more important than having any
single feature get into that release.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2014-12-10 12:06:11 -0500, Robert Haas wrote:
Ultimately, I think this is mostly going to be a question of what
Alvaro feels comfortable with; he's presumably going to have a better
sense of where and to what extent there might be bugs lurking than any
of the rest of us. But the point is worth considering, because I
think we would probably all agree that having a release that is stable
and usable right out of the gate is more important than having any
single feature get into that release.
Sure, 9.4 needs to be out of the gate. I don't think anybody doubts
that.
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one year from now it's a whole different ballgame than if we
try to go back to september. And I think there's pretty good arguments
for both.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Andres Freund (andres@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one year from now it's a whole different ballgame than if we
try to go back to september. And I think there's pretty good arguments
for both.
This should really be on its own thread for discussion... I'm leaning,
at the moment at least, towards the September release schedule. I agree
that having a later release would allow us to get more into it, but
there's a lot to be said for the consistency we've kept up over the past
few years with a September (our last non-September release was 8.4).
I'd certainly vote against planning for a mid-December release as, at
least in my experience, it's a bad idea to try and do December (or
January 1..) major releases. October might work, but that's not much of
a change from September. Late January or February would probably work
but that's quite a shift from September and don't think it'd be
particularly better. Worse, I'm nervous we might get into a habit of
longer and longer releases. Having yearly releases, imv at least, is
really good for the project and those who depend on it. New features
are available pretty quickly to end-users and people can plan around our
schedule pretty easily (eg- plan to do DB upgrades in January/February).
Thanks,
Stephen
On 12/10/2014 05:14 PM, Stephen Frost wrote:
* Andres Freund (andres@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one year from now it's a whole different ballgame than if we
try to go back to september. And I think there's pretty good arguments
for both.This should really be on its own thread for discussion... I'm leaning,
at the moment at least, towards the September release schedule. I agree
that having a later release would allow us to get more into it, but
there's a lot to be said for the consistency we've kept up over the past
few years with a September (our last non-September release was 8.4).
Can we please NOT discuss this in the thread about someone's patch? Thanks.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM8730e287691fedfb173de4b16e300acb1167d14622354807cc43048b59e3366cc246602f28fd12b980b07f7a09bb154c@asav-2.01.com
On 12/09/2014 09:11 PM, Tom Lane wrote:
Josh Berkus <josh@agliodbs.com> writes:
Question on COPY, though: there's reasons why people would want COPY to
dump in either physical or logical order. If you're doing COPY to
create CSV files for output, then you want the columns in logical order.
If you're doing COPY for pg_dump, then you want them in physical order
for faster dump/reload. So we're almost certainly going to need to have
an option for COPY.This is complete nonsense, Josh, or at least it is until you can provide
some solid evidence to believe that column ordering would make any
noticeable performance difference in COPY. I know of no reason to believe
that the existing user-defined-column-ordering option makes any difference.
Chill, dude, chill. When we have a patch, I'll do some performance
testing, and we'll see if it's something we care about or not. There's
no reason to be belligerent about it.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WMb2894de8245392ed88002ec749c2f24bd2037f66943d60b40bb06df9a9533454e42e8e1838829e1a4a3214110fc1560b@asav-3.01.com
On 2014-12-10 19:06:28 -0800, Josh Berkus wrote:
On 12/10/2014 05:14 PM, Stephen Frost wrote:
* Andres Freund (andres@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one year from now it's a whole different ballgame than if we
try to go back to september. And I think there's pretty good arguments
for both.This should really be on its own thread for discussion... I'm leaning,
at the moment at least, towards the September release schedule. I agree
that having a later release would allow us to get more into it, but
there's a lot to be said for the consistency we've kept up over the past
few years with a September (our last non-September release was 8.4).Can we please NOT discuss this in the thread about someone's patch? Thanks.
Well, it's relevant for the arguments made about the patches future...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
On 12/10/2014 05:14 PM, Stephen Frost wrote:
* Andres Freund (andres@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one year from now it's a whole different ballgame than if we
try to go back to september. And I think there's pretty good arguments
for both.
This should really be on its own thread for discussion... I'm leaning,
at the moment at least, towards the September release schedule. I agree
that having a later release would allow us to get more into it, but
there's a lot to be said for the consistency we've kept up over the past
few years with a September (our last non-September release was 8.4).
Can we please NOT discuss this in the thread about someone's patch? Thanks.
Quite. So, here's a new thread.
MHO is that, although 9.4 has slipped more than any of us would like,
9.5 development launched right on time in August. So I don't see a
good reason to postpone 9.5 release just because 9.4 has slipped.
I think we should stick to the schedule agreed to in Ottawa last spring.
Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/10/2014 09:35 PM, Tom Lane wrote:
Josh Berkus <josh@agliodbs.com> writes:
On 12/10/2014 05:14 PM, Stephen Frost wrote:
* Andres Freund (andres@2ndquadrant.com) wrote:
But the scheduling of commits with regard to the 9.5 schedule actually
opens a relevant question: When are we planning to release 9.5? Because
If we try ~ one year from now it's a whole different ballgame than if we
try to go back to september. And I think there's pretty good arguments
for both.This should really be on its own thread for discussion... I'm leaning,
at the moment at least, towards the September release schedule. I agree
that having a later release would allow us to get more into it, but
there's a lot to be said for the consistency we've kept up over the past
few years with a September (our last non-September release was 8.4).Can we please NOT discuss this in the thread about someone's patch? Thanks.
Quite. So, here's a new thread.
MHO is that, although 9.4 has slipped more than any of us would like,
9.5 development launched right on time in August. So I don't see a
good reason to postpone 9.5 release just because 9.4 has slipped.
I think we should stick to the schedule agreed to in Ottawa last spring.Comments?
If anything, it seems like a great reason to try to get 9.5 out BEFORE
we open the tree for 9.6/10.0/Cloud++. While there were technical
issues, 9.4 dragged a considerable amount because most people were
ignoring it in favor of 9.5 development.
So far, I haven't seen any features for 9.5 which would delay a more
timely release the way we did for 9.4. Anybody know of a bombshell
someone's going to drop on us for CF5?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Import Notes
Reply to msg id not found: WM3e4863365dde52cea1482b101f2f1583d6f6842c40189dc256a29706be45d8ed0afba4d39ffc73e3627f4af92cf94004@asav-3.01.com
On Wed, Dec 10, 2014 at 10:18 PM, Josh Berkus <josh@agliodbs.com> wrote:
So far, I haven't seen any features for 9.5 which would delay a more
timely release the way we did for 9.4. Anybody know of a bombshell
someone's going to drop on us for CF5?
I had wondered about that myself. What about jsquery? Is that something
that is planned for submission some time in the current cycle?
FWIW, I strongly doubt that I'll find time to work on anything like that
for 9.5.
--
Peter Geoghegan
