Closing some 8.4 open items

Tom Lane wrote:

If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

change cardinality() for multi-dim arrays?

Drop; there's no consensus that this should be changed

I don't think we should let this go quite so easily, as this is a new
function, so the bias should be to "getting it right" rather than "don't
change it".

The supplied functionality is not only surprising, but easily obtained
by an existing function. ISTM if we're supplying a new function it
should have new functionality.

cheers

andrew

On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

Tom Lane wrote:

If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

change cardinality() for multi-dim arrays?

       Drop; there's no consensus that this should be changed

I don't think we should let this go quite so easily, as this  is a new
function, so the bias should be to "getting it right" rather than "don't
change it".

I think it is right already, but the point is debatable.

The supplied functionality is not only surprising, but easily obtained by an
existing function. ISTM if we're supplying a new function it should have new
functionality.

Well, it's a compatibility function...

...Robert

Robert Haas wrote:

On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

Tom Lane wrote:

If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

change cardinality() for multi-dim arrays?

Drop; there's no consensus that this should be changed

I don't think we should let this go quite so easily, as this is a new
function, so the bias should be to "getting it right" rather than "don't
change it".

I think it is right already, but the point is debatable.

The supplied functionality is not only surprising, but easily obtained by an
existing function. ISTM if we're supplying a new function it should have new
functionality.

Well, it's a compatibility function...

compatible with what?

The other thing that frankly bothers me is that we appear to have
acquired this function by a curious process which involved no proposal
or discussion that I have discovered. If there had been proper and
adequate discussion before the item was committed I wouldn't be making a
fuss now, whether or not I agreed with the result.

cheers

andrew

On Sun, Apr 05, 2009 at 07:55:44AM -0400, Robert Haas wrote:

On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

Tom Lane wrote:

If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items

change cardinality() for multi-dim arrays?

� � � �Drop; there's no consensus that this should be changed

I don't think we should let this go quite so easily, as this �is a
new function, so the bias should be to "getting it right" rather
than "don't change it".

I think it is right already, but the point is debatable.

The supplied functionality is not only surprising, but easily
obtained by an existing function. ISTM if we're supplying a new
function it should have new functionality.

Well, it's a compatibility function...

It's actually in SQL:2008.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Andrew Dunstan <andrew@dunslane.net> writes:

Robert Haas wrote:

Well, it's a compatibility function...

compatible with what?

It's required by the SQL standard.

The other thing that frankly bothers me is that we appear to have
acquired this function by a curious process which involved no proposal
or discussion that I have discovered. If there had been proper and
adequate discussion before the item was committed I wouldn't be making a
fuss now, whether or not I agreed with the result.

I think Peter put it in under the assumption that meeting spec-required
syntax would always pass muster. It is however fair to question whether
he made the right extrapolation of the spec's definition to cases that
are not in the spec.

Personally I am in favor of changing it to give the total number of
array elements, on the grounds that (1) that's as defensible a reading
of the spec as the other and (2) it would add actual new functionality
rather than being only a relabeling of array_length.

I will leave that item on the Open Items list. I take it no one's
excited about the others?

regards, tom lane

On Sun, Apr 5, 2009 at 12:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

Robert Haas wrote:

Well, it's a compatibility function...

compatible with what?

It's required by the SQL standard.

The other thing that frankly bothers me is that we appear to have
acquired this function by a curious process which involved no proposal
or discussion that I have discovered. If there had been proper and
adequate discussion before the item was committed I wouldn't be making a
fuss now, whether or not I agreed with the result.

I think Peter put it in under the assumption that meeting spec-required
syntax would always pass muster.  It is however fair to question whether
he made the right extrapolation of the spec's definition to cases that
are not in the spec.

Personally I am in favor of changing it to give the total number of
array elements, on the grounds that (1) that's as defensible a reading
of the spec as the other and (2) it would add actual new functionality
rather than being only a relabeling of array_length.

I will leave that item on the Open Items list.  I take it no one's
excited about the others?

I'm excited about some of them, but not to the point of not wanting to
ship beta. So +1 for removing them as per your suggestions.

...Robert

On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:

I will leave that item on the Open Items list. I take it no one's
excited about the others?

When the windowing functions become a pain point, let's revisit :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter <david@fetter.org> writes:

On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:

I will leave that item on the Open Items list. I take it no one's
excited about the others?

When the windowing functions become a pain point, let's revisit :)

The \df thing? That's something it'd be okay to revisit during beta,
IMHO. The things I'd really like to get right before beta are the ones
that are going to require an initdb to change. Like, say, the
cardinality() issue ...

regards, tom lane

On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:

I'm excited about some of them, but not to the point of not wanting to
ship beta.  So +1 for removing them as per your suggestions.

I'm somewhat excited about posix_fadvise but my general feeling was
that it was best to do nothing anyways. I don't know how to test these
questions though because they depend a lot on workload and pgbench or
synthetic queries which stress prefetching aren't especially good at
measuring how fast pages get evicted.

As far as reimplementing regular index scans -- I don't currently see
any way to do it in a way that would satisfy your demands that
wouldn't be insanely complex. Hopefully I'm missing something obvious
and if someone sees what I would be happy to go ahead and implement
something. But everything I've tried has turned into a monster.

--
greg

Greg Stark <stark@enterprisedb.com> writes:

On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:

I'm excited about some of them, but not to the point of not wanting to
ship beta. �So +1 for removing them as per your suggestions.

I'm somewhat excited about posix_fadvise but my general feeling was
that it was best to do nothing anyways.

Yeah. One of the things in the back of my mind is that the planner is
going to prefer bitmap scans anyway for anything that fetches more than
a very few rows. So it's not clear that prefetching plain indexscans
is going to buy enough to justify a whole lotta work or ugliness there.

I'm content to throw this one on TODO.

regards, tom lane

On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:

David Fetter <david@fetter.org> writes:

On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:

I will leave that item on the Open Items list. I take it no one's
excited about the others?

When the windowing functions become a pain point, let's revisit :)

The \df thing? That's something it'd be okay to revisit during beta,
IMHO.

OK, I'll work on this tomorrow :)

Cheers,
David.

The things I'd really like to get right before beta are the ones
that are going to require an initdb to change. Like, say, the
cardinality() issue ...

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

--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter <david@fetter.org> writes:

On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:

The \df thing? That's something it'd be okay to revisit during beta,
IMHO.

OK, I'll work on this tomorrow :)

I think what we were lacking was consensus on what it should do,
not code ...

regards, tom lane

On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:

David Fetter <david@fetter.org> writes:

On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:

The \df thing? That's something it'd be okay to revisit during
beta, IMHO.

OK, I'll work on this tomorrow :)

I think what we were lacking was consensus on what it should do, not
code ...

I was thinking I'd knock out a proposal or two.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:

On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:

David Fetter <david@fetter.org> writes:

On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:

The \df thing? That's something it'd be okay to revisit during
beta, IMHO.

OK, I'll work on this tomorrow :)

I think what we were lacking was consensus on what it should do, not
code ...

I was thinking I'd knock out a proposal or two.

Please find enclosed one way to handle it, this being prepending
WINDOW to the result types in \df.

Another way, patch coming tomorrow, would be to add a \dw and remove
the functions where pg_proc.iswindowing is true from \df.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Tom Lane wrote:

Greg Stark <stark@enterprisedb.com> writes:

On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas <robertmhaas@gmail.com> wrote:

I'm excited about some of them, but not to the point of not wanting to
ship beta. ���So +1 for removing them as per your suggestions.

I'm somewhat excited about posix_fadvise but my general feeling was
that it was best to do nothing anyways.

Yeah. One of the things in the back of my mind is that the planner is
going to prefer bitmap scans anyway for anything that fetches more than
a very few rows. So it's not clear that prefetching plain indexscans
is going to buy enough to justify a whole lotta work or ugliness there.

I'm content to throw this one on TODO.

I am not inclined to add a TODO until we see actual value in doing it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Mon, Apr 06, 2009 at 10:51:22PM -0700, David Fetter wrote:

On Sun, Apr 05, 2009 at 05:57:46PM -0700, David Fetter wrote:

On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:

David Fetter <david@fetter.org> writes:

On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:

The \df thing? That's something it'd be okay to revisit during
beta, IMHO.

OK, I'll work on this tomorrow :)

I think what we were lacking was consensus on what it should do, not
code ...

I was thinking I'd knock out a proposal or two.

Please find enclosed one way to handle it, this being prepending
WINDOW to the result types in \df.

Another way, patch coming tomorrow, would be to add a \dw and remove
the functions where pg_proc.iswindowing is true from \df.

Here's another way, adding \dw.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Tom,

finishing posix_fadvise patch

Push to TODO

So has fadvise been completely dropped from 8.4, or only partially?

change psql's \df output for window functions?

Drop; there's no consensus that this should be changed

Also, Fetter is currently working on a \dw for 8.5.

Polymorphic types vs. domains

Push to TODO

Agreed.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus <josh@agliodbs.com> wrote:

Tom,

finishing posix_fadvise patch

       Push to TODO

So has fadvise been completely dropped from 8.4, or only partially?

Bitmap scans will support it, but index scans will not.

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

On Tue, Apr 7, 2009 at 10:42 PM, Josh Berkus <josh@agliodbs.com> wrote:

So has fadvise been completely dropped from 8.4, or only partially?

Bitmap scans will support it, but index scans will not.

And please note that we think bitmap scans are the larger part of
the win anyway. What's left undone there is some marginal mopup.

regards, tom lane