I had an idea that might improve parallel seqscans on the same relation.
If you have lots of concurrent seqscans going on a large relation, the
cache hit ratio is very low. But, if the seqscans are concurrent on the
same relation, there may be something to gain by starting a seqscan near
the page
John Hansen wrote:
currently, upper/lower does not work with 2+ byte unicode
characters,
on any OS under the C locale.
Sure it does. It's just that the defined behavior of the C
locale is often useless in practice.
select upper('æøå');
ERROR: invalid multibyte character for locale
Are you verifying that all the data that was committed was actually stored?
Or
just verifying that the database works properly after rebooting?
I verified the data.
Does pg startup increase the xid by some amount (say 1000 xids) after crash ?
Else I think you would also need to rollback a
On Thu, 2005-02-24 at 23:51 -0500, Bruce Momjian wrote:
Tatsuo Ishii wrote:
I do not object the changing UNICODE-UTF-8, but all these discussions
sound a little bit funny to me.
If you want to blame UNICODE, you should blame LATIN1 etc. as
well. LATIN1(ISO-8859-1) is actually a
Am Freitag, 25. Februar 2005 05:51 schrieb Bruce Momjian:
so I see what he is saying. We are not consistent in favoring the
official names vs. the common names.
I will work on a patch that people can review and test.
I think this is what we should do:
UNICODE = UTF8
ALT = WIN866
WIN =
I'm giving a talk next week on PostgreSQL 8, so I would like some input
from the community on a few issues, so that my answers are as close to
majority opinion as possible.
One of the most frequent set of questions I get asked is around the
development vision and release strategy of PostgreSQL.
Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
Might we set a rough date for Beta
On Thu, 24 Feb 2005 22:18:11 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Didn't we do that already?
No :( I promised to do it a couple of weeks ago but could not get to do it.
Now with Magnus's help I finaly did it. The last patch should be fine.
regards, tom lane
On Fri, 2005-02-25 at 02:47 -0400, Marc G. Fournier wrote:
On Fri, 25 Feb 2005, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle
On Fri, 2005-02-25 at 00:18 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features.
1. Executing outside the database engine, and therefore being able to
start/commit transactions. (This is *fundamentally* different from
our
current concept of functions, and I think that any implementation that
tries to gloss over the difference will be doomed to failure.)
Back in the early
On Thu, 24 Feb 2005 23:00:48 -0500 (EST)
Bruce Momjian pgman@candle.pha.pa.us wrote:
I read the following report from the NetBSD group:
http://kerneltrap.org/node/4680
It has some interesting points. First, they analyze how the fit with
other open source database offerings. Their
On Fri, 2005-02-25 at 00:34 -0800, Jeff Davis wrote:
I had an idea that might improve parallel seqscans on the same relation.
If you have lots of concurrent seqscans going on a large relation, the
cache hit ratio is very low. But, if the seqscans are concurrent on the
same relation, there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| Francisco Figueiredo Jr. [EMAIL PROTECTED] writes:
|
|Could I add another item?
|
|
|Could we have the row count of statements executed inside a
|procedure/function returned to client?
|
|
| IMHO that request is completely bogus; if
On Fri, 25 Feb 2005, Simon Riggs wrote:
- When is the next release due?
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month dev, 6 month beta) ...
subject
On Thu, Feb 24, 2005 at 10:27:03PM +0100, Ernst Herzberg wrote:
On Thursday 24 February 2005 21:43, Marc G. Fournier wrote:
[...]
pub/source/v.8.0.1/
postgresql-8.0.1.tar.bz2
postgresql-8.0.1.tar.bz2.md5
postgresql-8.0.1.tar.gz
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Essentially I'm thinking about the JDBC solution, but automated a bit
better.
So would your proposal invent a new stored procedure construct, or
just add some sugar to the existing function stuff? i.e. will you be
able to issue a
Merlin Moncure [EMAIL PROTECTED] writes:
1. Executing outside the database engine, and therefore being able to
start/commit transactions. (This is *fundamentally* different from our
current concept of functions, and I think that any implementation that
tries to gloss over the difference will
John Hansen [EMAIL PROTECTED] writes:
Sure it does. It's just that the defined behavior of the C
locale is often useless in practice.
select upper('æøå');
ERROR: invalid multibyte character for locale
HINT: The server's LC_CTYPE locale is probably incompatible with the
database
Urgh. This is clearly a bug. All the code in utils/adt seems to be
correctly set up to treat TimeADT as an integral value, but then the two
macros quoted are converting the value to float8 and back again ... so
what's actually on disk is the float8 equivalent of what the int64 value
is supposed
Teodor Sigaev [EMAIL PROTECTED] writes:
We'll obviously want to fix this going forward for efficiency reasons,
but it's an initdb-forcer because it'll change the on-disk
representation of time columns. So we can't change it in 8.0 or before.
So, will we do it? I can do, but I don't know: Is
Peter Eisentraut wrote:
Am Freitag, 25. Februar 2005 05:51 schrieb Bruce Momjian:
so I see what he is saying. We are not consistent in favoring the
official names vs. the common names.
I will work on a patch that people can review and test.
I think this is what we should do:
Bruce Momjian pgman@candle.pha.pa.us writes:
Peter Eisentraut wrote:
I think this is what we should do:
UNICODE = UTF8
ALT = WIN866
WIN = WIN1251
TCVN = WIN1258
OK, but what about latin1?
I think LATIN1 is fine as-is. It's a reasonably popular name for the
character set, and despite
Marc G. Fournier wrote:
On Fri, 25 Feb 2005, Simon Riggs wrote:
- When is the next release due?
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12
Marc G. Fournier wrote:
On Fri, 25 Feb 2005, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
On Fri, Feb 25, 2005 at 08:42:51AM -0500, D'Arcy J.M. Cain wrote:
They complain about release delays and the challenge of organizing
volunteers, just like us.
Is there any volunteer organization that's any different? :-)
FreeBSD doesn't seem to suffer much from either issue. Then again,
Marc G. Fournier [EMAIL PROTECTED] writes:
Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.
I thought we were looking at a 12-18 month cycle for 8.1? Which would put
beta
Simon Riggs wrote:
I'm giving a talk next week on PostgreSQL 8, so I would like some input
from the community on a few issues, so that my answers are as close to
majority opinion as possible.
One of the most frequent set of questions I get asked is around the
development vision and release
On Fri, 2005-02-25 at 05:34, Simon Riggs wrote:
I'm giving a talk next week on PostgreSQL 8, so I would like some input
from the community on a few issues, so that my answers are as close to
majority opinion as possible.
One of the most frequent set of questions I get asked is around the
I would agree that since we have a number of commercial developers who
do have intentions of working on specific items in 8.1, it would be nice
to list those items somewhere (the urgent section of the TODO seems
fine), but it is up to those developers to speak up.
I'd like to bundle pg_dump and
Tom Lane wrote:
Although we've dropped the idea of letting the ARC problem drive a very
short 8.1 cycle, I would still like to see us shoot for a relatively
short 8.1 cycle --- less than a year for sure. The main reason is that
I think we'll be flushing out performance and feature issues in the
Bruce Momjian wrote:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.
I agree there is no way to accurately predict such things, however there
was a
Matthew T. O'Connor matthew@zeut.net writes:
One thing to consider while discussing the length of the cycle is what
features are people planning on putting in? The 8.0 cycle had to be
long due to the many huge improvements. I'm not aware of any 8.1 plans
that are that ambitious, so why
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Yea, probably September, but you can't dump a huge feature on us in
August either without having talked about it first, so knowing the date
might not be that helpful.
I thought we were looking at a 12-18 month cycle for 8.1?
On Fri, Feb 25, 2005 at 10:49:59AM -0500, Bruce Momjian wrote:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.
How do other open source projects
Am Freitag, 25. Februar 2005 15:42 schrieb Marc G. Fournier:
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month dev, 6 month beta) ...
subject to change,
Am Freitag, 25. Februar 2005 16:26 schrieb Bruce Momjian:
OK, but what about latin1?
The following character set names are specified in the SQL standard and
therefore somewhat non-negotiable:
SQL_CHARACTER
GRAPHIC_IRV
LATIN1
ISO8BIT
UTF16
UTF8
UCS2
SQL_TEXT
SQL_IDENTIFIER
So we have to use
Matthew T. O'Connor matthew@zeut.net writes:
Are there any big projects are people
working on to get into 8.1?
I'm privately hoping to get bitmap index operations into 8.1 (that is,
build a bitmap of tuple locations from an index, possibly AND or OR the
results of multiple indexes, and finally
Am Freitag, 25. Februar 2005 16:49 schrieb Bruce Momjian:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.
A good guess for the features contained in
Simon Riggs [EMAIL PROTECTED] writes:
I'm happy with the Zen approach of there is no answer, the code comes
when it is time and HACKERS list IS the process.
Many people take the lack of a planned release date as clear indication
that there is no strictly controlled release process,
I wouldn't mind seeing people be a little more vocal on the hackers list
about what they plan to be doing, just so that there's not duplication
of effort. But trying to assemble that into some sort of published
Master Plan sounds to me like just a recipe for making ourselves look
foolish when the
On Fri, 25 Feb 2005, Peter Eisentraut wrote:
Am Freitag, 25. Februar 2005 15:42 schrieb Marc G. Fournier:
Based on past discussions on a 12 to 18 month dev cycle for 8.1, and based
on past track record, I'd say closer to the 18 month, so figure on June
'06, with freeze in January of '06 (12 month
On Fri, 25 Feb 2005, Jim C. Nasby wrote:
Unless generating the splits requires a non-trivial amount of work, I
see no reason not to have them.
its all automated ... still wish I could figure out a way of splitting off
*just* libppq, since that would drop downloads of the full package
On Fri, 25 Feb 2005, Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 08:42:51AM -0500, D'Arcy J.M. Cain wrote:
They complain about release delays and the challenge of organizing
volunteers, just like us.
Is there any volunteer organization that's any different? :-)
FreeBSD doesn't seem to suffer much
Simon,
Welcome back! Ready to get to work? I need to talk to you about some
stuff
- When is the next release due?
Each of our previous 4 releases has taken between 11 and 14 months. So,
early 2006 would not be unlikely; however, we have set no dates yet.
- What will be in
On Fri, 2005-02-25 at 13:38 +, Simon Riggs wrote:
On Fri, 2005-02-25 at 00:34 -0800, Jeff Davis wrote:
I had an idea that might improve parallel seqscans on the same relation.
If you have lots of concurrent seqscans going on a large relation, the
cache hit ratio is very low. But, if
Jeff Davis [EMAIL PROTECTED] writes:
(1) Do we care about reverse scans being done with synchronized
scanning? If so, is there a good way to know in advance whether it is
going to be a forward or reverse scan (i.e. before heap_getnext())?
There are no reverse heapscans --- the only case where
Tom,
As a proposal: feature freeze maybe early summer (June or July), beta
maybe Aug/Sep, final as always when it's ready (maybe Oct/Nov with
a good tailwind).
I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season? I can
Tom,
Well, if you take the summer-vacation argument seriously, then nothing
will get done between May and September anyway, so we may as well freeze
in May ;-)
I'd be happy with saying June 1.
Hey, you and Bruce are the ones who'll get stuck with all the code checking if
nobody else is
Josh Berkus josh@agliodbs.com writes:
I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season?
...
So I'd advocate either freezing in May, or in September.
Well, if you take the summer-vacation argument seriously, then nothing
Josh Berkus wrote:
I thought we were trying to get away from a midsummer feature freeze,
due to the general lack of personnel in that season?
Better to do feature freeze with no one around than development or
release preparations with no one around, no?
--
Peter Eisentraut
On Fri, 25 Feb 2005, Josh Berkus wrote:
Also, what do you think of Simon's plan for a 2-stage feature freeze?
Maybe not so far apart ... maybe a month apart?
I missed that ... could you re-summarize?
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL
On Fri, 25 Feb 2005, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season?
...
So I'd advocate either freezing in May, or in September.
Well, if you take the summer-vacation
select upper('æøå');
ERROR: invalid multibyte character for locale
HINT: The server's LC_CTYPE locale is probably
incompatible with the database encoding.
Consequently it seems that is does not work.
It fails on my machine should not be read as it doesn't
work for anyone.
It
Josh Berkus josh@agliodbs.com writes:
Also, what do you think of Simon's plan for a 2-stage feature freeze? Maybe
not so far apart ... maybe a month apart?
I didn't feel a need for it. It's true that the closer we get to
feature freeze, the smaller the patch you should expect to drop on us
Marc,
I missed that ... could you re-summarize?
Sure, Simon proposed that we have a feature freeze for major features (like
bitmapped indexes and 2PC) before the feature freeze for minor
features (like new system views). The reason being that the major features
need a lot more code
On Fri, 25 Feb 2005, Peter Eisentraut wrote:
Josh Berkus wrote:
I thought we were trying to get away from a midsummer feature freeze,
due to the general lack of personnel in that season?
Better to do feature freeze with no one around than development or
release preparations with no one around, no?
On Fri, 2005-02-25 at 12:54 -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
(1) Do we care about reverse scans being done with synchronized
scanning? If so, is there a good way to know in advance whether it is
going to be a forward or reverse scan (i.e. before heap_getnext())?
John Hansen [EMAIL PROTECTED] writes:
It fails on my machine should not be read as it doesn't
work for anyone.
It all depends on how your local mbstowcs() works.
Ok,... Do you have an example of a system on which it works?
On HPUX 10.20, mbstowcs seems to treat all byte values as
Markus Schaber [EMAIL PROTECTED] writes:
Tom Lane schrieb:
given the improved support in 8.0 for anonymous record types, we could
in theory have the backend invent a record type on-the-fly to match
whatever list of OUT parameters a particular function has.)
It would not be necessarily on the
Jeff Davis [EMAIL PROTECTED] writes:
I didn't consider that. Is there a reason the regression tests assume
the results will be returned in a certain order (or a consistent order)?
We use diff as the checking tool.
regards, tom lane
---(end of
Peter Eisentraut wrote:
Am Freitag, 25. Februar 2005 16:26 schrieb Bruce Momjian:
OK, but what about latin1?
The following character set names are specified in the SQL standard and
therefore somewhat non-negotiable:
SQL_CHARACTER
GRAPHIC_IRV
LATIN1
ISO8BIT
UTF16
UTF8
UCS2
On HPUX 10.20, mbstowcs seems to treat all byte values as
single-byte characters in C locale, so my sample-of-one says
that it works everywhere ;-).
Right, so for the sample SQL I sent earlier, the result would be the same as
the input?
That's hardly a working upper/lower
If a
John Hansen [EMAIL PROTECTED] writes:
Right, so for the sample SQL I sent earlier, the result would be the same as
the input?
That's hardly a working upper/lower
[ shrug... ] It works per the locale definition, which is that only
7-bit-ASCII a-z/A-Z get converted.
The bottom line here
Hello I saw this :
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-0247
is 8.0.1 Safe ?
is there a patch ?
thank you
Leonel
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
Marc G. Fournier [EMAIL PROTECTED] writes:
Josh Berkus josh@agliodbs.com writes:
I thought we were trying to get away from a midsummer feature freeze, due to
the general lack of personnel in that season?
I concur with Josh on this ... that kinda wastes the 'two months of
summer' when ppl
yo mero [EMAIL PROTECTED] writes:
Hello I saw this :
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-0247
is 8.0.1 Safe ?
No --- at least not the source-code releases. Red Hat's 8.0.1 RPMs
include the patch, and I think the latest community RPMs do too.
is there a patch ?
On Fri, Feb 25, 2005 at 01:27:09PM -0400, Marc G. Fournier wrote:
On Fri, 25 Feb 2005, Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 08:42:51AM -0500, D'Arcy J.M. Cain wrote:
They complain about release delays and the challenge of organizing
volunteers, just like us.
Is there any volunteer
On Fri, 25 Feb 2005 14:40:25 -0500, Tom Lane [EMAIL PROTECTED] wrote:
yo mero [EMAIL PROTECTED] writes:
Hello I saw this :
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2005-0247
is 8.0.1 Safe ?
No --- at least not the source-code releases. Red Hat's 8.0.1 RPMs
include the
On Fri, 25 Feb 2005, Jim C. Nasby wrote:
Hrm, guess it's been too long since I've been subscribed to -current. I
know they're still working bugs out of 5.x, but I attributed that to the
major changes made. One of the big reasons I've been such a fan of FBSD
is the technical direction was set by a
Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 10:49:59AM -0500, Bruce Momjian wrote:
I have no idea how to predict what will be in 8.1. I couldn't predict
what would be in 8.0 until just before feature freeze, so the idea that
we would have any clue about 8.1 is unrealistic.
How do
Tom Lane wrote:
Bruce used to try to describe our releases as being oriented towards some
particular goal, but I always thought that these were after-the-fact
descriptions that had nothing to do with the real development process.
The truth is that individual developers work on what they feel
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Josh Berkus josh@agliodbs.com writes:
I thought we were trying to get away from a midsummer feature freeze, due
to
the general lack of personnel in that season?
I concur with Josh on this ... that kinda wastes the 'two months
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
If this were an ordinary devel cycle then I'd be fine with it running a
year, but I think we really do need to plan for a shorter than normal
cycle so we can clean up 8.0 kinks in a reasonably timely fashion.
Let's see how much 8.0
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
If this were an ordinary devel cycle then I'd be fine with it running a
year, but I think we really do need to plan for a shorter than normal
cycle so we can clean up 8.0 kinks in a reasonably timely fashion.
Title: Modifying COPY TO
I am interested in hacking COPY TO such that one can specify that
rows are copied in a certain index order. I got as far as
src/backend/commands/copy.c:CopyTo(), and it looks like I would need
to modify the call to heap_beginscan() so that it uses a key. However,
Dave Held [EMAIL PROTECTED] writes:
I am interested in hacking COPY TO such that one can specify that
rows are copied in a certain index order. I got as far as=20
src/backend/commands/copy.c:CopyTo(), and it looks like I would need
to modify the call to heap_beginscan() so that it uses a key.
* Dave Held ([EMAIL PROTECTED]) wrote:
A possibility that I would like to pursue is to keep the staging data
from the previous day, do a COPY TO, import the new data into
another staging table with a COPY FROM, then export the fresh
data with another COPY TO. Then, I can write a fast C/C++
On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
I didn't consider that. Is there a reason the regression tests assume
the results will be returned in a certain order (or a consistent order)?
We use diff as the checking tool.
Doesn't the SQL
On Fri, 2005-02-25 at 13:30 -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
I didn't consider that. Is there a reason the regression tests assume
the results will be returned in a certain order (or a consistent order)?
We use diff as the checking tool.
Well, that does make
Instead of just being able to specify an index to use, how hard would it
be to allow COPY TO to work from a generic query instead of just a
table? That way you wouldn't need to do a diff, you could just export
only new records. ISTM there's far more use for copying from a query
result that just
On Fri, 2005-02-25 at 18:03 -0600, Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
I didn't consider that. Is there a reason the regression tests assume
the results will be returned in a certain order (or a consistent
Sorry, please disregard my ramblings. I thought it was a different
question.
---
pgman wrote:
Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
I
Jim C. Nasby wrote:
Instead of just being able to specify an index to use, how hard would it
be to allow COPY TO to work from a generic query instead of just a
table? That way you wouldn't need to do a diff, you could just export
only new records. ISTM there's far more use for copying from a
Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
I didn't consider that. Is there a reason the regression tests assume
the results will be returned in a certain order (or a consistent order)?
We use diff as the
On Fri, Feb 25, 2005 at 04:30:17PM -0800, Jeff Davis wrote:
On Fri, 2005-02-25 at 18:03 -0600, Jim C. Nasby wrote:
On Fri, Feb 25, 2005 at 01:30:57PM -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
I didn't consider that. Is there a reason the regression tests assume
the
On 2005-02-25, Dave Held [EMAIL PROTECTED] wrote:
A possibility that I would like to pursue is to keep the staging data
from the previous day, do a COPY TO, import the new data into
another staging table with a COPY FROM, then export the fresh
data with another COPY TO. Then, I can write a
On Feb 25, 2005, at 10:36 AM, Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
Are there any big projects are people
working on to get into 8.1?
I'm privately hoping to get bitmap index operations into 8.1 (that is,
build a bitmap of tuple locations from an index, possibly AND or OR
Jim C. Nasby [EMAIL PROTECTED] writes:
but I also hate to burden the developers with rewriting a lot of
regression tests when their time could be better spent elsewhere.
Certainly, but I suspect it's just a matter of adding ORDER BY to
everything, which just about anyone (even myself!) should
Jim C. Nasby [EMAIL PROTECTED] writes:
... ISTM there's far more use for copying from a query
result that just copying by index order.
Yeah. The other point is that it's entirely likely that an external
sort will be faster than using an indexscan to produce the sorted order.
If you instead
On Fri, Feb 25, 2005 at 11:51:40PM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
but I also hate to burden the developers with rewriting a lot of
regression tests when their time could be better spent elsewhere.
Certainly, but I suspect it's just a matter of adding ORDER
91 matches
Mail list logo
