-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Alvaro Herrera
Sent: Friday, April 13, 2007 4:24 PM
To: Tom Lane
Cc: [EMAIL PROTECTED]; PostgreSQL Performance; Steve
Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM]
Hello
I searched some notes about this topic. I didn't find any usefull sample.
Lot of samples are about external stored procedures and others about using
table expression like
create function foo(i1)
returns table (a1 int)
as
return table(select a1 from tab)
isn't clear if table
Dann Corbit [EMAIL PROTECTED] writes:
Instead of sorting, I suggest the quickselect() algorithm, which is
O(n).
What for? Common cases have less than half a dozen entries. That is
not the place we need to be spending engineering effort --- what we
need to worry about is what's the choice
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the concern about condition redundancy should be attacked
separately. How about just comparing whether they have common prefixes
of conditions? I admit I don't understand what would happen with
indexes defined like (lower(A), B, C) versus (A,
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Has anyone got any thoughts about the best way to do this?
How about doing both: sort the index by index scan cost; then pick the
first index on the list and start adding indexes when they lower the
cost. When adding each index,
On Fri, 2007-04-13 at 18:48 -0400, Tom Lane wrote:
Has anyone got any thoughts about the best way to do this?
I don't think we know enough to pick one variant that works in all
cases. This requires more detailed analysis of various cases.
Lets put in a parameter to allow the options to be
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 12. April 2007 17:08 schrieb Gregory Stark:
Unless there's a makefile variable that is included in both CFLAGS and
LDFLAGS that the user could use instead? But then that wouldn't work on
architectures where ld is used instead of gcc
Tatsuo Ishii [EMAIL PROTECTED] writes:
Sigh. From the first day when JOHAB was supported (back to 7.3 days),
it should had not been in the server encodings. JOHAB's second byte
definitely contain 0x41 and above. *johab*.map just reflect the
fact. I think we should remove JOHAB from the
Tatsuo Ishii [EMAIL PROTECTED] writes:
I think the best way to proceed is probably to fix this in HEAD but
not back-patch it. During a dump and reload the encoding can be
corrected to something safe.
Ok. Shall I go ahead and remove JOHAB in HEAD?
+1 for me.
regards,
