On 12 May 2011, at 22:07, Gauthier, Dave wrote:
> Ya, I'm sort of coming to that conclusion because of a different
> consideration. I'm worried about whether or not the triggers will be fired
> immediately after each record inserted, or once ot the end, or something else.
That's just the diffe
On 05/13/2011 11:38 AM, Tim Uckun wrote:
That's an interesting idea. Since I am building this app from scratch
I suppose I could create different schemas for different applications
instead of using different databases. I wonder how rails and active
record can deal with that. I'll take a look and
On 05/12/11 8:38 PM, Tim Uckun wrote:
I sometimes think it'd be nice if Pg offered the ability to translate schema
to "databases", so it runs with a single database and multiple schema, and
you "connect" to a schema, MySQL style. It'd help people who want to use
multiple databases on a machine an
>
> I sometimes think it'd be nice if Pg offered the ability to translate schema
> to "databases", so it runs with a single database and multiple schema, and
> you "connect" to a schema, MySQL style. It'd help people who want to use
> multiple databases on a machine and query between them, though o
On 05/12/2011 12:04 PM, Tim Uckun wrote:
or carefully structure your dblink joins so they can perform efficiently,
possibly using temp tables as a sort of materialized view.
According to the documents unless you are writing procedural code with
cursors when you touch the dblink view it will pul
David suggested using a guesstimate default date along with a boolean to
indicate when you're using guesstimates. I think this is a solid approach,
but if the default expected_by idea doesn't work for you, a boolean would
still make this a lot easier on the Rails side.
It sounds like you're using
On Thu, May 12, 2011 at 11:26:38AM -0700, bubba postgres wrote:
> I would just like to get some clarification from the list on how to do a
> pg_dump on the slave in the face of "canceling statement due to conflict
> with recovery".
> The following links seem to indicate that If I start an idle tran
Dne 12.5.2011 16:23, Phoenix Kiula napsal(a):
> Hi
>
> Been reading some old threads (pre 9.x version) and it seems that the
> consensus is to avoid doing massive deletes from a table as it'll
> create so much unrecoverable space/gaps that vacuum full would be
> needed. Etc.
>
> Instead, we might
Ya, I'm sort of coming to that conclusion because of a different consideration.
I'm worried about whether or not the triggers will be fired immediately after
each record inserted, or once ot the end, or something else. Just too risky.
I'm going to go with the discrete insert statements in the
On Thu, May 12, 2011 15:51, David Johnston wrote:
>>
>> +Infinity was chosen as a default to avoid the complexities of
>> dealing with NULL logic in SELECTS. I suppose that the simplest
>> solution is to go with a date of -12-31 and treat that value
>> like infinity.
>
> The "just make it wor
"Gauthier, Dave" writes:
> Does...
>insert into mytbl (col1) values ('a'),('b'),('c');
> ... insert records 'a','b','c' in that order while...
>insert into mytbl (col1) values ('c'),('b'),('a');
> ... insert the records in the opposite order?
I believe so, but it s
See here:
http://www.postgresql.org/docs/9.0/static/sql-values.html
Implied is that the supplied data set will be returned in the same order as
written unless an ORDER BY is used to re-order the listing prior to it being
spit out the other end.
1, 3, 2 = > VALUES = > 1, 3, 2
1, 3, 2 = >
Dne 12.5.2011 17:37, Phoenix Kiula napsal(a):
> [mydomain] src > cd pg_reorg-1.1.5
>
> [mydomain] pg_reorg-1.1.5 > gmake
> Makefile:13: ../../src/Makefile.global: No such file or directory
> gmake: *** No rule to make target `../../src/Makefile.global'. Stop.
>
> [mydomain] pg_reorg-1.1.5 >
>
>
> The column expected_by contains an estimated time of arrival for a
particular
> conveyance. When a row is initialized this value is unknown some of the
> time. The expected_by value is reset to the arrived_at value on UPDATE if
> and only if expected_by is greater than arrived_at.
>
> Conveyanc
Hi:
Does...
insert into mytbl (col1) values ('a'),('b'),('c');
... insert records 'a','b','c' in that order while...
insert into mytbl (col1) values ('c'),('b'),('a');
... insert the records in the opposite order?
The order matters because there are triggers on t
On Thu, May 12, 2011 at 8:23 AM, Phoenix Kiula wrote:
> Hi
>
> Been reading some old threads (pre 9.x version) and it seems that the
> consensus is to avoid doing massive deletes from a table as it'll
> create so much unrecoverable space/gaps that vacuum full would be
> needed. Etc.
> Any ideas o
On Thu, May 12, 2011 at 10:02 PM, Bob Pawley wrote:
> Hi
>
> Can anyone point me to an example of how to use the Postgresdac Dump
> component??
>
>
>
Below URL will give more detail information about Postgresdac dump::
http://www.microolap.com/products/connectivity/postgresdac/help/TPSQLDump/M
I would just like to get some clarification from the list on how to do a
pg_dump on the slave in the face of "canceling statement due to conflict
with recovery".
The following links seem to indicate that If I start an idle transaction on
the master I should be able to do the pg_dump, but I tried th
On Thu, May 12, 2011 12:40, David Johnston wrote:
>
> Not a huge fan of Infinity as a value...but that just may be lack of
> experience.
>
> I'd probably remove the NOT NULL constraint on expected_at and deal
> with tri-value logic; or also include a boolean (is_expected) and
> form queries like
> -Original Message-
> From: pgsql-general-ow...@postgresql.org [mailto:pgsql-general-
> ow...@postgresql.org] On Behalf Of James B. Byrne
> Sent: Thursday, May 12, 2011 9:12 AM
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] How to handle bogus nulls from ActiveRecord
>
>
> So so
Hi
Can anyone point me to an example of how to use the Postgresdac Dump component??
Bob
[snip]
> You can easily install it as a contrib . Just read the installation guide or
> the man Page.
Thanks Eric. How though?
The instructions here --
http://reorg.projects.postgresql.org/pg_reorg.html -- are woefully
incomplete.
I have a standard PG install on WHM/Cpanel type server. I kn
On Thu, May 12, 2011 at 17:23, Phoenix Kiula wrote:
> Been reading some old threads (pre 9.x version) and it seems that the
> consensus is to avoid doing massive deletes from a table as it'll
> create so much unrecoverable space/gaps that vacuum full would be
> needed. Etc.
Just running DELETE wi
In response to Phoenix Kiula :
> Hi
>
> Been reading some old threads (pre 9.x version) and it seems that the
> consensus is to avoid doing massive deletes from a table as it'll
> create so much unrecoverable space/gaps that vacuum full would be
> needed. Etc.
>
> Instead, we might as well do a
Am 12.05.2011 16:38, schrieb Phoenix Kiula:
On Thu, May 12, 2011 at 10:33 PM, Eric Ndengang
wrote:
Am 12.05.2011 16:23, schrieb Phoenix Kiula:
Hi
Been reading some old threads (pre 9.x version) and it seems that the
consensus is to avoid doing massive deletes from a table as it'll
create so
Durumdara wrote:
>>> C1.) begin read committed
>>> C1.) starting this query
>>> C1.) query running
>>> C2.) begin read committed
>>> C2.) update Lookup set Name = "New2" where ID = 2
>>> C2.) commit
>>> C1.) query running
>>> C1.) query finished
>>>
>>> Is it possible to the first joins (before C2
Hi
Been reading some old threads (pre 9.x version) and it seems that the
consensus is to avoid doing massive deletes from a table as it'll
create so much unrecoverable space/gaps that vacuum full would be
needed. Etc.
Instead, we might as well do a dump/restore. Faster, cleaner.
This is all well
On Wed, May 11, 2011 at 11:18 PM, Phoenix Kiula wrote:
> I have a text column in a table, which I want to search through --
> seeking the occurrence of about 300 small strings in it.
>
> Let's say the table is like this:
>
> table1 (
> id bigint primary key
> ,mytext text
>
thank you depesz, your help was very useful!
Am 12.05.2011 13:19, schrieb hubert depesz lubaczewski:
On Thu, May 12, 2011 at 10:56:20AM +0200, Andreas Laggner wrote:
Hi list,
i always vaccumed my postgresql automatically with crontab, because
autovacuum is not suitable for my applications. W
On 11.05.11 17:31, "Tom Lane" wrote:
>You really, really, really need to fix whatever is preventing you from
>using pooling. Opening a database connection to run one query is just
>horridly inefficient.
Very true. I did not mean that anything actually prevents us from using
pooling. We just
On 11.05.11 17:04, "t...@fuzzy.cz" wrote:
>We had exactly the same problem and persistent connection solved it.
First testing with persistent connections seems to work like a charm. Will
do some thorough testing and watch the memory load. Hopefully, I will not
trip over some sort of pitfall. Go
Hi,
we are trying to minimize data storage size as possible. We'd like to
replace BOX and POINT datatypes with our own. We don't need double precision
- 4 bytes integer would be totally fine.
I tried following experiment in which custom data type vPointInt of 4
integers takes 28 bytes. Why is that
Hi,
Just to sum things up:
On Wednesday 04 May 2011 19:21:42 Tom Lane wrote:
> Well, I think it's foolish to imagine that a client library should try
> to do transparent reconnection: it's somewhere between difficult and
> impossible to keep track of all the server-side state that the
> applicati
It is required for application data verification filters that
default values for table columns are known to ActiveRecord when
creating a new row. So ActiveRecord obtains the default values from
the tables dynamically and assigns them to their appropriate column
attributes. The problem we encounter
On Thu, May 12, 2011 at 10:56:20AM +0200, Andreas Laggner wrote:
> Hi list,
>
> i always vaccumed my postgresql automatically with crontab, because
> autovacuum is not suitable for my applications. With version 8.2 it
> works perfect for me with this command line:
>
> 00 02 * * *postgres /usr
Andreas Laggner writes:
> Hi list,
>
> i always vaccumed my postgresql automatically with crontab, because
> autovacuum is not suitable for my applications. With version 8.2 it
> works perfect for me with this command line:
>
> 00 02 * * *postgres /usr/bin/vacuumdb -d gis -z
>
> But not with
Hi!
2011/5/12 Albe Laurenz :
> Durumdara wrote:
>>Two table:
>>Main
>>Lookup
>>
>>The query is:
>>select Main.*, Lookup.Name
>>left join Lookup on (Main.Type_ID = Lookup.ID)
>
> hat's not correct SQL, but I think I understand what you mean.
Sorry, the from is missed here... :-(
>
>
>>Lookup:
>>I
Hi list,
i always vaccumed my postgresql automatically with crontab, because
autovacuum is not suitable for my applications. With version 8.2 it
works perfect for me with this command line:
00 02 * * *postgres /usr/bin/vacuumdb -d gis -z
But not with 9.0, because vacuumdb now wants to ha
Durumdara wrote:
>Two table:
>Main
>Lookup
>
>The query is:
>select Main.*, Lookup.Name
>left join Lookup on (Main.Type_ID = Lookup.ID)
hat's not correct SQL, but I think I understand what you mean.
>Lookup:
>ID Name
>1 Value1
>2 Value 2
>3 Value 3
>
>Many records is in Main table (for example 1
2011/5/12 Craig Ringer :
> On 05/11/2011 03:16 PM, AI Rumman wrote:
>>
>> I am trying to migrate a database from Postgresql 8.2 to Postgresql 8.3
>> and getting the following error:
>>
>> pg_restore: [archiver (db)] Error from TOC entry 2764; 0 29708702 TABLE
>> DATA originaldata postgres
>> pg_res
40 matches
Mail list logo
