> -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: [PERFO
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 attributes
"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
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 varie
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 instea
> 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 f
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.
