Thanks Tom for the reply (if you could reply all, as I'm not currently
subscribed just yet).
[Since our post, we've down an explicit vacuum on the tbluser.id column, and
things are looking much much better, there were 0 rows in the pg_stats table
for that table...]
Incidently, tbluser.Id is a bigint (hence the '' wrapped around the in
clause, otherwise the infamous postgres issue crops up not matching the Int
literal number with the bigint index, and reverts to nasty table scan).
Both our production and our dump/restore servers are UNICODE.
Incidently, if I do a VACUUM Analyze on this table:
comptoolkit=# VACUUM analyze tbluser;
ERROR: Invalid UNICODE character sequence found (0xf8335c)
Me thinks somehow there is a hashed_password with some dodgy characters, but
I'm not sure how we'll find that row, or what we'll do with that when we
find it. (Any thoughts?). Could be why statistics getting removed?
ANy thoughts along this would be good, we're over the performance hump, but
it's always nice to know more...
cheers,
Paul Smith
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Monday, 2 June 2003 3:31 PM
> To: George Papastamatopoulos
> Cc: pgsql-performance@postgresql.org; Paul Smith
> Subject: Re: [PERFORM] FW: Query Plan problem
>
>
> George Papastamatopoulos
> <George.Papastamatopoulos@lawlex.com.au> writes:
> >> ... WHERE tblUser.id IN
> >>
> ('102','103','104','105','106','107','108','109','110','111','
> 112','113','
> >>
> 114','115','116','117','118','119','120','121','122','123','12
> 4','125','12
> > ...
>
> What's the datatype of tblUser.id? What indexes do you have on the
> table?
>
> Also, are both databases built with the same locale/encoding support
> and initdb-time choices? What are they?
>
> regards, tom lane
>
