tip "A block containing an EXCEPTION clause is
significantly more expensive to enter ..." in PostgreSQL documentation
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
i...@postgresql-consulting.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
i...@postgresql-consulting.com
, and certainly some wait event classification will be needed
for both approaches and its much better to implement one rather than
two different.
And at least, I will be interesting in reviewing your approach.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
--
Ilya
://www.enterprisedb.com
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
i...@postgresql-consulting.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
time locks.
After that it is possible to implement something more precise. (As far
as I know, Greg Smith works on some sort of wait events, but it seems
to me there are a lot of work to do to implement exact analog of OWI)
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell
could be as worse as
one long wait. That is why it is important, but I thing propper
sampling provides good estimation for this.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Ilya
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
i...@postgresql-consulting.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
entries
* are small, so the risk of running out of memory is minimal in practice.
*/
But it does have significant overhead.
I will say that it is a bit more than overhead for production use.
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
/
PostgreSQL Development, 24x7 Support, Training Services
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
i...@postgresql-consulting.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
, Training Services
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
i...@postgresql-consulting.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
a brief but
pretty useful tutorial how LWLock-related code lives in Postgres. Also
I am thankful to Heikki Linnakangas and Magnus Hagander for answering
some of my stupid questions about procarray internals.
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
That is quite useful feature to implement smth. like message queues
based on database and so on.
Now there is possibility to jump over luck of such feature in Postgres
using current advisory lock implementation (pg_try_advisory_xact_lock
to determine if somebody already acquired log on particular
Nice to hear and thumbs up! I've just start planning to migrate one of
my telco 3Tb database running blunt oracle to coachDb but now of
course postgres looks better. Hopefully stupid transactions will be
abrogated to
wbr Ilya
On Thu, Apr 1, 2010 at 12:33 PM, Dave Page dp...@postgresql.org
13 matches
Mail list logo