On Thu, Jul 25, 2013 at 2:57 AM, Some Developer
wrote:
> The added advantage of removing load from the app servers so they can
> actually deal with serving the app is a bonus.
Uhm...I don't know what application you are developing, but I don't
buy your explaination.
While it is true that you are
Hi all,
Hope this question is not too stupid but..
I am trying to do something like this
create table cats (a text,b text);
create rule cats_test as on update to cats do set a = new.b;
Can i manipulate column "a" sort of like this... or is there a better way.
I would like to do this a
Our current database size is
1 Terabyte
Thanks
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Tablespace-on-Postgrsql-tp5765056p5765082.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-genera
On 24/07/13 20:33, Jeff Janes wrote:
On Tue, Jul 23, 2013 at 5:29 PM, Some Developer
wrote:
I've done quite a bit of reading on stored procedures recently and the
consensus seems to be that you shouldn't use them unless you really must.
I think that mostly speaks to the method you used for fi
On 7/24/2013 1:32 PM, devonline wrote:
We do have large Database with RAID 10. we do have Replication(Hot backup) .
we would like to have the same on PostgreSQL when we migrate to PostgreSQL .
Should we create separate tablespaces for Database and its objects or
pg_default is fine as you have
We do have large Database with RAID 10. we do have Replication(Hot backup) .
we would like to have the same on PostgreSQL when we migrate to PostgreSQL .
Should we create separate tablespaces for Database and its objects or
pg_default is fine as you have mentioned earlier
Thanks a lot
Dev Onli
On Wed, Jul 24, 2013 at 2:05 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Lonni J Friedman escribió:
>>> I'm using the RPMs from yum.postgresql.org on RHEL6. Is this
>>> expected, intentional behavior? Do I really need to dump & reload to
>>> upgrade between beta releases of 9.3, or is there
On Wed, Jul 24, 2013 at 11:50 AM, pg noob wrote:
> In PostgreSQL 8.4...
>
> I am wondering if autovacuum will periodically rebuild indexes?
It doesn't rebuild indexes, it marks empty index pages for reuse.
> If not, how advisable is it to reindex periodically?
Here described the recommendations
On Wed, Jul 24, 2013 at 1:50 PM, pg noob wrote:
>
> Hi all,
>
> In PostgreSQL 8.4...
>
> I am wondering if autovacuum will periodically rebuild indexes?
it will not. REINDEX requires a heavy lock and for most applications
it would be just plain untenable to be run without some type of
application
Alvaro Herrera writes:
> Lonni J Friedman escribió:
>> I'm using the RPMs from yum.postgresql.org on RHEL6. Is this
>> expected, intentional behavior? Do I really need to dump & reload to
>> upgrade between beta releases of 9.3, or is there some more efficient
>> way?
> We try to avoid forcing
Lonni J Friedman escribió:
> I'm using the RPMs from yum.postgresql.org on RHEL6. Is this
> expected, intentional behavior? Do I really need to dump & reload to
> upgrade between beta releases of 9.3, or is there some more efficient
> way?
We try to avoid forcing initdb between beta versions, b
Greetings,
I just got around to upgrading from 9.3-beta1 to 9.3-beta2, and was
surprised to see that the server was refusing to start. In the log,
I'm seeing:
2013-07-24 13:41:47 PDT [7083]: [1-1] db=,user= FATAL: database files
are incompatible with server
2013-07-24 13:41:47 PDT [7083]: [2-1] d
On 7/24/2013 12:31 PM, devonline wrote:
I am new to PostgreSQL.
I would like to know whether to use/pg_default/ Table space to create
Database and its objetcs or to create custom Table space?
I could not find what is recommended .
tablespaces are usually only useful on very large scale se
Hi all,
In PostgreSQL 8.4...
I am wondering if autovacuum will periodically rebuild indexes?
If not, how advisable is it to reindex periodically?
We recently had a case of unique index corruption which ended up allowing
duplicate
primary key IDs to get inserted and caused widespread data model
I am new to PostgreSQL.
I would like to know whether to use /pg_default/ Table space to create
Database and its objetcs or to create custom Table space?
I could not find what is recommended .
Thanks
Dev Online
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/
On Tue, Jul 23, 2013 at 5:29 PM, Some Developer
wrote:
> I've done quite a bit of reading on stored procedures recently and the
> consensus seems to be that you shouldn't use them unless you really must.
I think that mostly speaks to the method you used for finding things
to read. This is a well
Andres Freund writes:
> I think fixing this for 9.4 is fine, but due to the compat issues I
> think it's to late for 9.3.
Agreed -- this is effectively a protocol change, albeit a pretty minor
one, so I can't see back-patching it.
regards, tom lane
--
Sent via pgsql-ge
On 2013-07-24 13:48:23 -0400, Tom Lane wrote:
> Vik Fearing writes:
> > Also worth mentioning is bug #7766.
> > http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postgresql.org
>
> Yeah, did you read that whole thread? The real issue here is going to
> be whether client-side code f
Vik Fearing writes:
> Also worth mentioning is bug #7766.
> http://www.postgresql.org/message-id/e1tlli5-0007tr...@wrigleys.postgresql.org
Yeah, did you read that whole thread? The real issue here is going to
be whether client-side code falls over on wider-than-32-bit counts.
We can fix the back
On 07/24/2013 04:04 PM, Vik Fearing wrote:
> On 07/22/2013 06:20 PM, Jeff Janes wrote:
>> On Fri, Jul 19, 2013 at 3:20 PM, Natalie Wenz
>> wrote:
>>> Hi all,
>>>
>>> I am moving some data from one table to another in 9.2.4, and keep seeing
>>> this strange scenario:
>>>
>>> insert into newtable
On 24/07/2013 14:58, Merlin Moncure wrote:
On Wed, Jul 24, 2013 at 8:31 AM, Some Developer
wrote:
On 24/07/13 14:21, Gauthier, Dave wrote:
I find stored procedures to be a God-send. The alternative, external
code, is the risky, difficult and often poorer performing approach to the
problems s
On 07/22/2013 06:20 PM, Jeff Janes wrote:
> On Fri, Jul 19, 2013 at 3:20 PM, Natalie Wenz wrote:
>> Hi all,
>>
>> I am moving some data from one table to another in 9.2.4, and keep seeing
>> this strange scenario:
>>
>> insert into newtable select data from oldtable where proc_date >= x and
>> p
On Wed, Jul 24, 2013 at 8:31 AM, Some Developer
wrote:
> On 24/07/13 14:21, Gauthier, Dave wrote:
>>
>> I find stored procedures to be a God-send. The alternative, external
>> code, is the risky, difficult and often poorer performing approach to the
>> problems sp's solve. What better way to in
On 07/24/2013 06:31 AM, Some Developer wrote:
Thank you all for the responses. I feel better about making use of them
now.
Now for one final question: I was planning on using plpython2u to write
my stored procedures since Python is a language I am very familiar with.
I understand that many p
I find stored procedures to be a God-send. The alternative, external code, is
the risky, difficult and often poorer performing approach to the problems sp's
solve. What better way to interact programatically with your database than
WITH your database?
The only people that I see frown upon th
On Wed, Jul 24, 2013 at 7:52 AM, Aaron Abreu wrote:
> a NON-technical version...
>
> st.procedures and automation are great...
>
> but...
> sounds like everybody is dancing around the main theme..
> so lets say it
> that dreaded word that developers and DBA's cring to hear...
> the one part of
Hi,
> In other words an API in the database.
+1. People code apps and then disappear, because once the development is
over they are not available in the company any more. And each thing you
hardwire in the app becomes a stopper. Meanwhile, every company will have
at least one DBA, who can manage/u
2013/7/24 Aaron Abreu :
> a NON-technical version...
>
> st.procedures and automation are great...
>
> but...
> sounds like everybody is dancing around the main theme..
> so lets say it
> that dreaded word that developers and DBA's cring to hear...
> the one part of our job that we all hate...
2013/7/24 Aaron Abreu :
> a NON-technical version...
>
> st.procedures and automation are great...
>
> but...
> sounds like everybody is dancing around the main theme..
> so lets say it
> that dreaded word that developers and DBA's cring to hear...
> the one part of our job that we all hate...
a NON-technical version...
st.procedures and automation are great...
but...
sounds like everybody is dancing around the main theme..
so lets say it
that dreaded word that developers and DBA's cring to hear...
the one part of our job that we all hate...
DOCUMENTATION !
My worst fear is s
Hi Kevin,
Il 23/07/2013 21:54, Kevin Goess ha scritto:
We're seeing a problem with some of our processes hanging on locks.
The select below makes it look like it's *waiting* for a ShareLock on
transactionid, but it *has* an ExclusiveLock on the same value in
virtualxid.
You are seeing a 'bl
On Wed, Jul 24, 2013 at 2:29 AM, Some Developer
wrote:
> I've done quite a bit of reading on stored procedures recently and the
> consensus seems to be that you shouldn't use them unless you really must.
I believe because most developers are not DBAs, and therefore are
scared about something they
32 matches
Mail list logo
