Pavel Stehule wrote:
> 4.1)
>  To SELECT a random row, use:
>     SELECT col
>     FROM tab
>     ORDER BY random()
>     LIMIT 1;
> + On bigger tables this solution is slow. Please, find smarter
> solution on network.

Well, give me a better example that works.

> 4.6)
> ILIKE is slow, specially on multibyte encodings. If is possible use
> FULLTEXT. LIKE '%some%' is slow always .. thing about FULLTEXT.

I added a mention of "full text indexing" for word searches.

> 4.11.2)
> + Alternatively (on PostgreSQL 8.2.0 and all later releases) you could
> RETURNING clause for retrieving used SERIAL value, e.g.,
> new_id = execute("SELECT INSERT INTO person(name) VALUES('Blaise
> Pascal') RETURNING id");

Agreed.  I have updated the text to suggest RETURNING be used and
reduced the other examples.  The web site should have the updated
content shortly but CVS will have FAQ.html as well soon.

> 4.19)
> + most of problems with invalid OIDs in cache are solved in PostgreSQL
> 8.3. Please remeber, so every replanning of SQL statements needs time.
> Write your application, they can exist without cache invalidation.

Agreed.  Item removed.

  Bruce Momjian  <[EMAIL PROTECTED]>

  + If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to