On 2012-02-24, amit sehas 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. Does
> thi
On 2012-01-27, 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 recording
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 ha
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 traf
"Joshua D. Drake" :
> 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 ORM) >= 3.1 is brok
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 avail
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 retaini
On Sat, Feb 25, 2012 at 5:54 PM, Stefan Keller 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 structure
