From: | "Markus Wanner" <markus(at)bluegap(dot)ch> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: setting up scan keys |
Date: | 2009-08-26 06:53:00 |
Message-ID: | 20090826085300.27286vnuha4wj45o@mail.bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Tom,
Quoting "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Either the SK_ROW_MEMBER flag is entirely wrong..
Uhm.. yes, that's it. I've been under the impression that for an index
scan with multiple attributes, I need to assemble scan keys with
SK_ROW_MEMBER, SK_ROW_END and SK_ROW_HEADER. I now realize that's
plain wrong and I can simply provide as many scan keys as I have
attributes to scan for, without fiddling with any flag or subtype. The
code in question now uses the simpler ScanKeyInit() and looks as
follows:
for (i = 0; i < numKeys; i++)
{
attnum = idx_info->ii_KeyAttrNumbers[i];
get_sort_group_operators(tdesc->attrs[attnum - 1]->atttypid,
false, true, false,
NULL, &eq_func, NULL);
ScanKeyInit(&skeys[i], i + 1, BTEqualStrategyNumber,
get_opcode(eq_func), values[attnum - 1]);
}
Thank you very much for your help, that quickly got me on track again.
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Rick Gigger | 2009-08-26 07:36:01 | Re: 8.5 release timetable, again |
Previous Message | Craig Ringer | 2009-08-26 05:20:51 | Re: BUG #4996: postgres.exe memory consumption keeps going up |