On 2012-02-24, amit sehas cu...@yahoo.com wrote:
If we have a query of the form:
Select *, (Select * FROM T2 WHERE p2 = T1.p1) FROM T1 ORDER BY 1 WHERE p3 = 75
In the above query there is a subselect in the target list and the
ORDERBY has an ordinal number which indicates order by column 1.
On 2012-01-27, bbo...@free.fr bbo...@free.fr wrote:
Hello!
again quite a stupid problem i regularly run into
and that i still haven't solved yet...
again i used a type timestamp to keep a track of modification time,
and again it gets stupid and confusing.
oops! (when
What I'm trying to determine is: should I plan on using pgbouncer?
With Rails Passenger, do the app server processes take and hold connections
to the db? Or take release with queries/connections?
This is not a scalability question; given the traffic the site will have I only
need a small
On 02/25/2012 08:13 AM, Scott Ribe wrote:
What I'm trying to determine is: should I plan on using pgbouncer?
With Rails Passenger, do the app server processes take and hold connections to
the db? Or take release with queries/connections?
This is not a scalability question; given the
Joshua D. Drake j...@commandprompt.com:
Where pgbouncer might come in handy here, is that it can open more
connections than you have httpd processes, and thus you will reduce
the
fork cost of the new process just because someone hits the website.
Unfortunatelly, ActiveRecords (Rails
On 25/02/12 04:39, Durumdara wrote:
Hi!
We planned to port some very old DBASE db into PGSQL.
But somebody said in a developer list that he tried with PGSQL (8.x)
and it was very unstable in Windows (and it have problem when many
users use it).
Another people also said that they used PGSQL
An application I have written connects to a remote Postgresql 8.3/8.4
database using Lazarus/FreePascal components, Zeoslib, but it has been
timing out too often as the network gets busy in a bursty mode. When the
network times out, restarting the app retrieves the data quickly, it is
always
Hi,
Recently Mike Stonebraker identified four areas where old elephants
lack performance [1]:
1. Buffering/paging
2. Locking/Multithreading
3. WAL logging
4. Latches (aka memory locks for concurrent access of btree structures
in buffer pool?).
He claims having solved these issues while
On Sat, Feb 25, 2012 at 5:54 PM, Stefan Keller sfkel...@gmail.com wrote:
Hi,
Recently Mike Stonebraker identified four areas where old elephants
lack performance [1]:
1. Buffering/paging
2. Locking/Multithreading
3. WAL logging
4. Latches (aka memory locks for concurrent access of btree
