Matthew Wakeling wrote:
Okay, I don't know quite what's happening here. Tom, perhaps you could
advise. Running opannotate --source, I get this sort of stuff:
/*
* Total samples for file :
".../postgresql-8.4beta2/src/backend/access/gist/gistget.c"
*
* 6880 0.2680
*/
and then:
Tom Lane wrote:
Adam Gundy <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Oh, it coerces the type all right, just not in the direction you'd like.
is there a reason it doesn't coerce to a type that's useful to the
planner (ie varchar in my case),
In this case I think t
Tom Lane wrote:
Adam Gundy <[EMAIL PROTECTED]> writes:
hmm. unfortunately it did turn out to be (part) of the issue. I've
discovered that mixing char and varchar in a stored procedure does not
coerce the types, and ends up doing seq scans all the time.
Oh, it coerces the type all
Richard Huxton wrote:
Adam Gundy wrote:
On Thu, Apr 10, 2008 at 8:52 AM, Adam Gundy <[EMAIL PROTECTED]> wrote:
Richard Huxton wrote:
How many distinct values do you have in groups.groupid and
group_access.group_id?
for the small database (since it shows the same problem):
group_
On Thu, Apr 10, 2008 at 8:52 AM, Adam Gundy <[EMAIL PROTECTED]> wrote:
> Richard Huxton wrote:
> > How many distinct values do you have in groups.groupid and
> group_access.group_id?
> >
>
> for the small database (since it shows the same problem):
>
> group
Richard Huxton wrote:
Adam Gundy wrote:
I'm hitting an unexpected problem with postgres 8.3 - I have some
tables which use varchar(32) for their unique IDs which I'm attempting
to join using some simple SQL:
select *
from group_access, groups
where group_access.groupid = groups.g
I'm hitting an unexpected problem with postgres 8.3 - I have some
tables which use varchar(32) for their unique IDs which I'm attempting
to join using some simple SQL:
select *
from group_access, groups
where group_access.groupid = groups.groupid and
group_access.uid = '7275359408f44591d0
