Thank you for the response.
Our new server went down in memory from 20Gig to 16Gig. Our old server has
100 databases in the cluster, and we will be splitting up into multiple
servers so we thought the the decrease was acceptable.
dirty_background_ratio is 10 on the new box and 1 on the old.
On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
People periodically ask for extensions flavored more or less like this,
but I'm suspicious of building any such thing into the core. There's too
little commonality in the exact conditions they want to search on.
Leaving it at
On Tue, Feb 4, 2014 at 8:35 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Sergey Konoplev escribió:
On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
People periodically ask for extensions flavored more or less like this,
but I'm suspicious of building any such thing
2014-02-03 Evan Martin postgre...@realityexists.net:
Thanks for that oid::regprocedure trick! A query like this is fairly
simple once you know it, but completely non-obvious when you don't.
I'm not sure what conditions others want to search on (couldn't find it in
the list archives), but by
Sergey Konoplev escribió:
On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
People periodically ask for extensions flavored more or less like this,
but I'm suspicious of building any such thing into the core. There's too
little commonality in the exact conditions they
On Tue, Feb 4, 2014 at 8:35 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Sergey Konoplev escribió:
On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
People periodically ask for extensions flavored more or less like this,
but I'm suspicious of building any such thing
Sergey Konoplev gray...@gmail.com writes:
On Tue, Feb 4, 2014 at 8:35 AM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Sergey Konoplev escribió:
On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
People periodically ask for extensions flavored more or less like this,
but
Tom Lane-2 wrote
I wonder whether we shouldn't address this by adding a few examples
of that type of trick to the docs. Not sure where, though ...
Probably the Wiki would be a better place to put this kind of material. A
link to there from 21. Managing Database would seem to be most
In a nutshell: I think the difficulty of dropping functions is
inconsistent with the difficulty of dropping other objects and I'd like
to see this inconsistency fixed.
So I don't agree with the suggestion of matching function names using a
regex, since that's not supported for other types of
Evan Martin wrote
In a nutshell: I think the difficulty of dropping functions is
inconsistent with the difficulty of dropping other objects and I'd like
to see this inconsistency fixed.
So I don't agree with the suggestion of matching function names using a
regex, since that's not
Sergey Konoplev escribió:
I understand the POV of both Evan and you here. However, I think that
there might be a good solution for this particular case - to allow
dropping functions by name only if it has the only signature, but if
there are 2 or more signatures then print an error
* David Johnston (pol...@yahoo.com) wrote:
Evan Martin wrote
So I don't agree with the suggestion of matching function names using a
regex, since that's not supported for other types of objects. To explain
the use case a little better:
Uh, we could add such support, which might be very
On 04/02/2014 19:56, David Johnston wrote:
No, they cannot. If the arguments change you are dealing with an entirely
new object. And often you end up keeping the old function around for
backward-compatibility.
Of course, I understand that it's a different object, technically, but
from the
Hi,
Gentoo Linux, PostgreSQL 9.2.4.
I'm trying to find out why postgres uses a specific time zone that I
don't expect to be used, and without any success so far. The situation
seems strange to me, but I could probably miss something.
Here is what I found out.
1. There are no any per-database
On 02/04/2014 11:23 AM, Sergey Konoplev wrote:
Hi,
Gentoo Linux, PostgreSQL 9.2.4.
I'm trying to find out why postgres uses a specific time zone that I
don't expect to be used, and without any success so far. The situation
seems strange to me, but I could probably miss something.
Here is what
On Tue, Feb 4, 2014 at 11:29 AM, Adrian Klaver adrian.kla...@gmail.com wrote:
On 02/04/2014 11:23 AM, Sergey Konoplev wrote:
Gentoo Linux, PostgreSQL 9.2.4.
I'm trying to find out why postgres uses a specific time zone that I
don't expect to be used, and without any success so far. The
Sergey Konoplev escribió:
Hi,
Gentoo Linux, PostgreSQL 9.2.4.
I'm trying to find out why postgres uses a specific time zone that I
don't expect to be used, and without any success so far. The situation
seems strange to me, but I could probably miss something.
As far as I know, GMT is the
On 02/04/2014 01:21 PM, Alvaro Herrera wrote:
Sergey Konoplev escribió:
Hi,
Gentoo Linux, PostgreSQL 9.2.4.
I'm trying to find out why postgres uses a specific time zone that I
don't expect to be used, and without any success so far. The situation
seems strange to me, but I could probably
On 02/04/2014 12:09 PM, Sergey Konoplev wrote:
On Tue, Feb 4, 2014 at 11:29 AM, Adrian Klaver adrian.kla...@gmail.com wrote:
On 02/04/2014 11:23 AM, Sergey Konoplev wrote:
Gentoo Linux, PostgreSQL 9.2.4.
I'm trying to find out why postgres uses a specific time zone that I
don't expect to be
Every row of my table has a double[] array of approximately 30K numbers. I
have ran a few tests, and so far everything looks good.
I am not pushing the limits here, right? It should be perfectly fine to
store arrays of 30k double numbers, correct?
--
View this message in context:
On Tue, Feb 4, 2014 at 12:41 PM, Adrian Klaver adrian.kla...@gmail.com wrote:
On 02/04/2014 12:09 PM, Sergey Konoplev wrote:
So the postgresql.conf is the one created by initdb for this particular
installation?
If that is the case it would seem that initdb could not determine what the
On 02/04/2014 01:52 PM, AlexK wrote:
Every row of my table has a double[] array of approximately 30K numbers. I
have ran a few tests, and so far everything looks good.
I am not pushing the limits here, right? It should be perfectly fine to
store arrays of 30k double numbers, correct?
--
View
On 02/04/2014 12:31 PM, Rob Sargent wrote:
On 02/04/2014 01:21 PM, Alvaro Herrera wrote:
Perhaps building from source does make a guess at TZ. I am not residing
in the Navaho national territory, but is that just Mountain time?
Yes:
No large deletes, just inserts/updates/selects. What are the potential
problems with deletes?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Is-it-reasonable-to-store-double-arrays-of-30K-elements-tp5790562p5790568.html
Sent from the PostgreSQL - general mailing list
On Tue, Feb 4, 2014 at 2:59 PM, Rob Sargent robjsarg...@gmail.com wrote:
On 02/04/2014 01:52 PM, AlexK wrote:
Every row of my table has a double[] array of approximately 30K numbers. I
have ran a few tests, and so far everything looks good.
I am not pushing the limits here, right? It should
I will be always reading/writing the whole array. The table is about 40GB. It
replaces two tables, parent and child, using about 160 GB together.
--
View this message in context:
Adrian Klaver adrian.kla...@gmail.com writes:
On 02/04/2014 12:31 PM, Rob Sargent wrote:
Perhaps building from source does make a guess at TZ. I am not residing
in the Navaho national territory, but is that just Mountain time?
Yes:
http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
On 02/04/2014 03:44 PM, Tom Lane wrote:
Adrian Klaver adrian.kla...@gmail.com writes:
On 02/04/2014 12:31 PM, Rob Sargent wrote:
Perhaps building from source does make a guess at TZ. I am not residing
in the Navaho national territory, but is that just Mountain time?
Yes:
On Tue, Feb 04, 2014 at 10:56:28AM -0800, David Johnston wrote:
If you are doing version controlled upgrades you should not be using this
function but during the RD phase I can imagine it would come in quite
handy.
Or add Tom's remarks to a little corner of contrib/, or as Tom
suggested, the
29 matches
Mail list logo
