Thanks for the reply. I was afraid it would come down to testing each individual
situation.ยต
The table I mentioned (6 million+ records) actually is a phonebook. And searching and
filtering is possible on almost any combination of fields. So there's an index on each
individual field now and that'
Stijn Vanroye wrote:
I don't want to but in, I just find this an interesting discussion
and would like to add my 2 cents:
I have read this in the manual: (PostgreSQL 7.4beta4 documentation,
Chapter 11.3 Multicolumn Indexes) Qoute: "Multicolumn indexes should
be used sparingly. Most of the time, an
ards,
Stijn Vanroye
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: dinsdag 1 juni 2004 10:44
To: John Wells
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] Large table search question[Scanned]
John Wells wrote:
> Guys,
>
> I have a general question about desig
John Wells wrote:
Guys,
I have a general question about designing databases for large data sets.
I was speaking with a colleague about an application we're preparing to
build. One of the application's tables will potentially contain 2 million
or more names, containing (at least) the fields first_n
"John Wells" <[EMAIL PROTECTED]> writes:
> A common lookup the application will require is the full name, so prefix +
> first_name + middle_name + last_name.
> My friend's suggestion was to create a "lookup field" in the table itself,
> which would contain a concatenation of these fields created d
Guys,
I have a general question about designing databases for large data sets.
I was speaking with a colleague about an application we're preparing to
build. One of the application's tables will potentially contain 2 million
or more names, containing (at least) the fields first_name, last_name,