2007/10/9, Bruce Momjian <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
> > 2007/10/9, Bruce Momjian <[EMAIL PROTECTED]>:
> > > 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.
> >
> > Better universal solution doesn't exist. Exists only unelegant
> > solutions - but mutch faster.
> >
> > SELECT id, ...
> > FROM data
> > WHERE id = ANY(ARRAY(
> > SELECT (random()*:max_id)::int
> > FROM generate_series(1,20)))
> > LIMIT 1;
> >
> > max_id is host variable ~ real max id + some
> >
> > -- fast solution if id is PK of data
>
> Right. We really only want general solutions in the FAQ.
>
ok. I accept it. Can be some note there? Not this strange select.
> > > > 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.
> > >
> >
> > Cache invalidation isn't 100% protection before this error message.
> > With specific using of EXECUTE statement, you can get this message
> > too. But all temp tables related problems are solved.
>
> OK, let's see how many bug reports we get and we can always re-add it.
>
It's true :). You have to try really wild things inside plpgsql procedures.
Pavel
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
