Laurent Martelli wrote:

"Shridhar" == Shridhar Daithankar <[EMAIL PROTECTED]> writes:
  Shridhar> I am stripping the analyze outputs and directly jumping to
  Shridhar> the end.

Shridhar> Can you try following?

Shridhar> 1. Make all fields integer in all the table.

I can't do this because lists.values contains non integer data which
do not refer to a classes.id value. It may sound weird. This is
because it's a generic schema for a transparent persistence framework.

Fine .I understand. So instead of using a field value, can you use integer version of that field? (Was that one of your queries used that? I deleted the OP)



The solution for me would rather be to have varchar everywhere.

You need to cast every occurance of that varchar field appropriately, to start with. The performance might suffer as well for numbers.


  Shridhar> 2. Try following query EXPLAIN ANALYZE SELECT * from lists
  Shridhar> join classes on classes.id=lists.value where
  Shridhar> lists.id='16'::integer;

classes.id=lists.value::integer.


Try that.

The aim is absolute type compatibility. If types aren't exactly same, the plan is effectively dead.

<OT>
I would say postgresql enforces good habits in it's application developers, from a cultural POV.


Had C refused to compile without such strict type compatibility, we wouldn't have to worry about 16bit/32bit and 64 bit software. Just upgrade the compiler and everything is damn good..:-)

I doubt if C would have so popular with such strict type checking but that is another issue. I think pascal enforces such strict syntax.. Not sure though..
</OT>


Shridhar



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to