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
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-lea
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 node
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 par
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 operati
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.
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 operatio
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
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
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 p
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 lowe
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, De
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
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)
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
http://developer.postgr
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
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
"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
y exercise will be even
considered by core team...
So guess not really an answer
-Original Message-
From: Dennis Gearon [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 11:00 AM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Sorting Problem
total agreement,
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
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 the
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 t
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 en
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 broadcast)--
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 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 other
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 leve
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 varia
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 sel
athy 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,
kathy
Tom Lane wrote:
&qu
402
-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 ??
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 sear
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 d
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
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 c
35 matches
Mail list logo
