Re: [HACKERS] PostgreSQL does CAST implicitely between int and a domain derived from int during SELECT query
Le mercredi 26 août 2009 à 10:07 -0400, Andrew Dunstan a écrit : Isn't that cast effectively a no-op? What is no-op in English (I am French, pardon my English). I will update table definition in 5 minutes. Stay tuned. Kind regards, Jean-Michel signature.asc Description: Ceci est une partie de message numériquement signée
Re: [HACKERS] PostgreSQL does CAST implicitely between int and a domain derived from int during SELECT query
Jean-Michel Pouréj...@poure.com wrote: Le mercredi 26 août 2009 à 10:07 -0400, Andrew Dunstan a écrit : Isn't that cast effectively a no-op? What is no-op It's short for no operation -- meaning it doesn't really result in anything being done. You are probably way off base in your assumptions about why these queries aren't running faster, but have not provided enough information to determine the actual reason. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL does CAST implicitely between int and a domain derived from int during SELECT query
Jean-Michel Pouré wrote: Le mercredi 26 août 2009 à 10:07 -0400, Andrew Dunstan a écrit : Isn't that cast effectively a no-op? What is no-op in English (I am French, pardon my English). “no-op” means “an operation which does nothing”. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL does CAST implicitely between int and a domain derived from int during SELECT query
Jean-Michel Pouré wrote: Le mercredi 26 août 2009 à 10:07 -0400, Andrew Dunstan a écrit : Isn't that cast effectively a no-op? What is no-op in English (I am French, pardon my English). I will update table definition in 5 minutes. see http://en.wikipedia.org/wiki/No-op cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL does CAST implicitely between int and a domain derived from int during SELECT query
Jean-Michel Pouré wrote: Dear friends, Thank you for your previous answers. I am running into a systemic problem using Drupal under PostgreSQL 8.4 Drupal relies heavily on a domain derived from int: CREATE DOMAIN int_unsigned AS integer CONSTRAINT int_unsigned_check CHECK ((VALUE = 0)); Analysing slow queries, I noticed that PostgreSQL 8.4 would cast data from int4 to int_unsigned. Isn't that cast effectively a no-op? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL does CAST implicitely between int and a domain derived from int during SELECT query
Jean-Michel =?ISO-8859-1?Q?Pour=E9?= j...@poure.com writes: Analysing slow queries, I noticed that PostgreSQL 8.4 would cast data from int4 to int_unsigned. Details and query plan: http://drupal.org/node/559986 Some queries range between 400ms and 700ms. I see no reason whatever to think that that domain has anything to do with the choice of query plan. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PostgreSQL does CAST implicitely between int and a domain derived from int during SELECT query
Dear friends, Thank you for your previous answers. I am running into a systemic problem using Drupal under PostgreSQL 8.4 Drupal relies heavily on a domain derived from int: CREATE DOMAIN int_unsigned AS integer CONSTRAINT int_unsigned_check CHECK ((VALUE = 0)); Analysing slow queries, I noticed that PostgreSQL 8.4 would cast data from int4 to int_unsigned. Details and query plan: http://drupal.org/node/559986 Some queries range between 400ms and 700ms. The problem is that Drupal send 300 SQL queries per page. Of course these queries are cached in PHP. But not solving it makes it difficult to run a Drupal site under heavy load. What do you think? Is this because of the constraint or is this a possible feature missing in PostgreSQL. What solution do you recommend to solve this problem? Is there a way to use a custom type? Should we convert the schema to int and add local constraints? A lot of SQL code hanging around could be impacted and this seems like a serious issue to me. So it seems difficult to convert all these applications. For usability, it should be better to avoid cast between int and int_unsigned. Kind regards, Jean-Michel signature.asc Description: Ceci est une partie de message numériquement signée
