Am Freitag, 17. Dezember 2004 01:59 schrieb Michael Fuhr:
Initialize the database cluster with a locale setting other than C.
Hmmm...did I misunderstand something when I recommended using
ORDER BY LOWER(person.lastname)?
Those are two different ways to achieve the same effect in this
On Thu, Dec 16, 2004 at 23:33:00 -0500,
Greg Stark [EMAIL PROTECTED] wrote:
Chris Smith [EMAIL PROTECTED] writes:
Would doing it this way require an index:
create index lower_lastname on table x lower(lastname);
Well it doesn't *require* but it may be a good idea. It depends on
Bruno Wolff III [EMAIL PROTECTED] writes:
Using an index to do an order by is an order N operation.
No, using an index to do an order by is actually still n*log(n). You have to
traverse all the parent pages in the binary tree of the index as well.
This only goes to show how small the log(n)
Bruno Wolff III [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] wrote:
where postgres won't bother with the index since it will be slower than just
resorting the entire table.
Using an index to do an order by is an order N operation. Doing a sort
is an order N log N operation. For
Greg Stark [EMAIL PROTECTED] writes:
Bruno Wolff III [EMAIL PROTECTED] writes:
Using an index to do an order by is an order N operation.
No, using an index to do an order by is actually still n*log(n). You have to
traverse all the parent pages in the binary tree of the index as well.
Only
At 12:14 PM 12/17/2004 -0500, Tom Lane wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] wrote:
where postgres won't bother with the index since it will be slower
than just
resorting the entire table.
Using an index to do an order by is an order N operation. Doing
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
Bruno Wolff III [EMAIL PROTECTED] writes:
Using an index to do an order by is an order N operation.
No, using an index to do an order by is actually still n*log(n). You have to
traverse all the parent pages in the
On Fri, Dec 17, 2004 at 15:36:58 -0500,
Greg Stark [EMAIL PROTECTED] wrote:
Isn't that still nlog(n)? In the end you're going to have read in every page
of the index including all those non-leaf pages. Aren't there nlog(n) pages?
The depth of the tree is log N, but there are only N nodes. I
On Fri, Dec 17, 2004 at 15:12:18 -0600,
Bruno Wolff III [EMAIL PROTECTED] wrote:
On Fri, Dec 17, 2004 at 15:36:58 -0500,
Greg Stark [EMAIL PROTECTED] wrote:
Isn't that still nlog(n)? In the end you're going to have read in every page
of the index including all those non-leaf pages.
Bruno Wolff III [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] wrote:
Isn't that still nlog(n)? In the end you're going to have read in every page
of the index including all those non-leaf pages. Aren't there nlog(n) pages?
The depth of the tree is log N, but there are only N nodes. I
Problem i am having at the moment i cant get a true alpha sort to work
as Order By is sorting A..Z then a..z where i need aA..zZ sort
independant of case.
SQL Query
SELECT
*
FROM
person
WHERE
(salutation LIKE '%To%')
ORDER BY
person.lastname
Results
Ahsteit
Bloggs
Cap
Carrey
Diver
Duckula
Jamie Deppeler wrote:
Problem i am having at the moment i cant get a true alpha sort to
work as Order By is sorting A..Z then a..z where i need aA..zZ sort
independant of case.
Initialize the database cluster with a locale setting other than C.
--
Peter Eisentraut
On Fri, Dec 17, 2004 at 01:45:36AM +0100, Peter Eisentraut wrote:
Jamie Deppeler wrote:
Problem i am having at the moment i cant get a true alpha sort to
work as Order By is sorting A..Z then a..z where i need aA..zZ sort
independant of case.
Initialize the database cluster with a locale
Chris Smith [EMAIL PROTECTED] writes:
Would doing it this way require an index:
create index lower_lastname on table x lower(lastname);
Well it doesn't *require* but it may be a good idea. It depends on your
queries. It will NOT be useful for a query like:
select * from x order by
On Fri, Dec 17, 2004 at 11:28:36AM +1100, Jamie Deppeler wrote:
Problem i am having at the moment i cant get a true alpha sort to work
as Order By is sorting A..Z then a..z where i need aA..zZ sort
independant of case.
ORDER BY LOWER(person.lastname)
or
ORDER BY UPPER(person.lastname)
--
Would doing it this way require an index:
create index lower_lastname on table x lower(lastname);
?
Regards,
Chris Smith
Suite 30, 45-51 Huntley St, Alexandria, NSW 2015 Australia
Ph: +61 2 9517 2505
Fx: +61 2 9517 1915
email: [EMAIL PROTECTED]
web: www.interspire.com
Michael Fuhr wrote:
On Fri,
Perhaps the only way to get around the cache problem is to use an ISO-8859-x 8bit character set, but to have per table, or per column encoding attributes. And of course, ways to access what those are, in the Postgres API. Good for speed, but not for easy storing of multiple language/encodings per
On Wed, 13 Aug 2003, Dennis Gearon wrote:
Got a link to that section of the standard, or better yet, to a
'interpreted' version of the standard? :-)
The standard draft yes, an interpreted version, unfortunately not (unless
Date's book covers it and I can find where my copy is.
Here are some
Ok, thanks for all the discussion followed, vey educational :-))
But nobody really followed up my question :-(
For example, you have a table that is displayed in the browser. You want to let
the user do sorting on one or multible columns, including those which contain
localized strings.
If the
PROTECTED]
Sent: Tuesday, August 12, 2003 3:30 PM
To: Tom Lane
Cc: Tim Edwards; [EMAIL PROTECTED]
Subject: Re: [GENERAL] Sorting Problem
Do you mean that soring doesn't work for en_US locale ???
And, does encoding affect sorting at all ??
thanks,
kathy
Tom Lane wrote:
Tim Edwards [EMAIL PROTECTED] writes
Danke, Spacibo, gracias, thanks.
Tom Lane wrote:
Dennis Gearon [EMAIL PROTECTED] writes:
You mean in his own local environment? So all his programs, console operations, etc, will have the new encoding? Or 'LANG/LC_ALL' for Posgres specifically?
I mean he needs to run initdb with C as the
To: [EMAIL PROTECTED]
Cc: Tom Lane; Tim Edwards; [EMAIL PROTECTED]
Subject: Re: [GENERAL] Sorting Problem
This brings up another question:
Say initdb with en_US locale, and we have localized strings for
different
languages store in the db.
If we have a client in Germany, and want to see
On Tue, 12 Aug 2003, Maksim Likharev wrote:
If you are talking about everything that lies under so called LATIN-1 (
ISO-8859-1 ) en_US encapsulates ( at least suppose to ) all those
sorting rules, do not remember about accents tho.
It does not work like that. Different countries in europe
-Original Message-
From: Kathy zhu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 12, 2003 3:30 PM
To: Tom Lane
Cc: Tim Edwards; [EMAIL PROTECTED]
Subject: Re: [GENERAL] Sorting Problem
Do you mean that soring doesn't work for en_US locale ???
And, does encoding affect sorting at all ??
thanks
Dennis Gearon wrote:
How did you solve the problem .. :-)
inlining - most chars are just ascii and there are trivial optimizations
that can lead to just as fast as moving 4x the data around.
---(end of broadcast)---
TIP 6: Have you
Dennis Gearon wrote:
I agree with all of that except for one caveat:
all my reading, and just general off the cuff thinking, says that
processing variable width characters SIGNIFICANTLY slows an
application. It seems better to PROCESS fixed width characters (1,2,4
byte), and TRANSMIT
I think the question is how often are you passing data around/storing it
_in_ your application and how often are you processing it.
---
Dennis Gearon wrote:
I agree with all of that except for one caveat:
all my
Dennis Gearon [EMAIL PROTECTED] writes:
You mean in his own local environment? So all his programs, console operations, etc,
will have the new encoding? Or 'LANG/LC_ALL' for Posgres specifically?
I mean he needs to run initdb with C as the selected locale. It has
nothing to do with what
Dennis Gearon wrote:
Got a link to that section of the standard, or better yet, to a
'interpreted' version of the standard? :-)
Stephan Szabo wrote:
On Wed, 13 Aug 2003, Dennis Gearon wrote:
Dennis Bj?rklund wrote:
In the future we need indexes that depend on the locale (and a lot
of
Kathy zhu [EMAIL PROTECTED] writes:
Do you mean that soring doesn't work for en_US locale ???
Oh it works all right, it just doesn't agree with Tim's idea of what
sorted order is ;-)
regards, tom lane
---(end of
To help my understanding of this type of thing, when he reinits the database, can he get the PG backend to be running with a different LOCALE than the machine's?
Tom Lane wrote:
Tim Edwards [EMAIL PROTECTED] writes:
When I sort ASC on the varchar I get some strange results. Here a section of
Dennis Björklund wrote:
In the future we need indexes that depend on the locale (and a lot of other changes).
I agree. I've been looking at the web on this subject a lot lately. I am **NOT** a microslop fan, but SQL-SERVER even lets a user define a language(maybe encoding) down to the column
Currently I'm running PostgreSQL 7.2.3 and having a problem sorting.
I've got two colums of data, one Int4 one Varchar.
When I sort ASC on the varchar I get some strange results. Here a section of
data cut after running a sort. It starts with RM- then does RMT- Then goes
back for more RM-.
Tim Edwards [EMAIL PROTECTED] writes:
When I sort ASC on the varchar I get some strange results. Here a section of
data cut after running a sort. It starts with RM- then does RMT- Then goes
back for more RM-.
Sounds like you're in en_US locale, or at least something other than C
locale.
Do you mean that soring doesn't work for en_US locale ???
And, does encoding affect sorting at all ??
thanks,
kathy
Tom Lane wrote:
Tim Edwards [EMAIL PROTECTED] writes:
When I sort ASC on the varchar I get some strange results. Here a section of
data cut after running a sort. It starts with RM-
You mean in his own local environment? So all his programs, console operations, etc, will have the new encoding? Or 'LANG/LC_ALL' for Posgres specifically?
Tom Lane wrote:
Dennis Gearon [EMAIL PROTECTED] writes:
To help my understanding of this type of thing, when he reinits the database, can
36 matches
Mail list logo
