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 R&D 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, th
On 02/04/2014 03:44 PM, Tom Lane wrote:
Adrian Klaver 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_datab
Adrian Klaver 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
> The reason for
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:
http://postgresql.1045698.n5.nabble.com/Is-it-reasonable-to-store-double-arrays-of-30K-elements-tp5790562p5790570.ht
On Tue, Feb 4, 2014 at 2:59 PM, Rob Sargent 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 be perfectly fin
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 a
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:
http://en.wikipedia.org/wiki/List_of_tz_database_time_zone
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 Tue, Feb 4, 2014 at 12:41 PM, Adrian Klaver 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
> timezone is at init. I d
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:
http://postgr
On 02/04/2014 12:09 PM, Sergey Konoplev wrote:
On Tue, Feb 4, 2014 at 11:29 AM, Adrian Klaver 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 suc
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 miss
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
On Tue, Feb 4, 2014 at 11:29 AM, Adrian Klaver 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 situation
>> seems st
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
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 an
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 user
* 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
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 e
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 s
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 o
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
approp
Sergey Konoplev writes:
> On Tue, Feb 4, 2014 at 8:35 AM, Alvaro Herrera
> wrote:
>> Sergey Konoplev escribió:
>>> On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane wrote:
People periodically ask for extensions flavored more or less like this,
but I'm suspicious of building any such thing int
On Tue, Feb 4, 2014 at 8:35 AM, Alvaro Herrera wrote:
> Sergey Konoplev escribió:
>> On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane 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
>> > li
Sergey Konoplev escribió:
> On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane 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
2014-02-03 Evan Martin :
> 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 qualified function na
On Tue, Feb 4, 2014 at 8:35 AM, Alvaro Herrera wrote:
> Sergey Konoplev escribió:
>> On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane 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
>> > li
On Mon, Feb 3, 2014 at 10:09 AM, Tom Lane 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 the level of a
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. Tha
29 matches
Mail list logo
