On 9/11/15 4:50 AM, Sridhar N Bamandlapally wrote:
1) creating temporary table (say temp_users) on table users with
required data/columns-list and index on column user_id,
...this will be faster as there will be no joins with other tables
2) also need index on table auths_with_trans col
I have a table (A) with 750+ million records and another one (B) which is a
summary of information in A containing 30+million records.
Now I wonder whether it wouldn't be better to have B as an indexed
materialized view. Though not often, there will be situations where B has
to be updated.
In th
On 9/14/15 8:02 PM, Melvin Davidson wrote:
Actually, on further thought, you example shows that it works correctly
because we do want all references to the old schema to be changed to the
new schema, since all copies of functions will now reside in the new
schema. Otherwise, there is no point of
On 9/15/15 12:48 AM, Ben Chobot wrote:
We're in a situation where we would like to take advantage of the pgpass
hostname field to determine which password gets used. For example:
psql -h prod-server -d foo # should use the prod password
psql -h beta-server -d foo # should use the beta password
On 9/15/15 2:14 AM, Johann Spies wrote:
What are the pro's and con's of large materialized views vs. tables in a
case like this?
AFAIK a matview is essentially the same as a table under the covers, so
I don't believe there's any reason not to use one. At some point we'll
have incremental refr
Hello all,
To avoid replication of some tables, I use a specific replication set.
For example, with 2 nodes 'node1' and 'node2' and a table 'test' which
content shall not be replicated, I do the following:
mydb=# CREATE TABLE test (i INT PRIMARY KEY NOT NULL);
mydb=# SELECT bdr.table_set_repli
Hello,
I am using a foreign data wrapper where i get a portion of my data
pre-loaded , i.e I get a set of rows before hand . So now i want to run
multiple update queries on this loaded data , write the changes to file ,
load the next set and continue with updates again.
How should i try
I still do not see any problem. The whole purpose of the function is to
copy ALL sequences , tables and functions to "new" schema, so new.old WILL
exist.
I don't see how you can possibly write a function that references a schema
that does not yet exist!
Again, please provide a _working_ example o
That is correct. But table old will NOT be converted to new because
only the schema name is converted. And table "old" WILL exist because it
will also be copied.
I have tested and it works properly.
Please do not provide hypothetical examples. Give me an actual working
example that causes the pro
On 7 August 2015 at 12:34, Thom Brown wrote:
>
> On 30 July 2015 at 13:35, Rowan Collins wrote:
>
>> Hi,
>>
>> When working with partition sets, we're seeing occasional errors of
>> "could not find inherited attribute..." in Select queries. This is
>> apparently caused when an "ALTER TABLE ... N
On Sep 15, 2015, at 12:27 AM, Jim Nasby wrote:
>
> On 9/15/15 12:48 AM, Ben Chobot wrote:
>> We're in a situation where we would like to take advantage of the pgpass
>> hostname field to determine which password gets used. For example:
>>
>> psql -h prod-server -d foo # should use the prod pass
Igor,
I understand your point, however, I have spent over a week making a
function
that previously did very little do a lot.
Naming a table the same as a schema is a very silly idea.
Unless you care to take the time to provide a full
schema, and function that fails for reasonable , practical desig
To make the casual user's life easier, in the face of this reality, it
would nice if the routine would generate a reasonably attempted "diff"
between the two so that all changes can be reviewed in a structured manner
aided by correctly configured tools and advice.
On Tue, Sep 15, 2015 at 12:20 PM,
David,
Yes, it would be nice, but
1. I am still working also on bringing over the comments for various objects
2. What you request is currently beyond my capability. Not to mention that
there already
are existing tools that do that, albeit they are not free.
On Tue, Sep 15, 2015 at 12:27 PM,
Sylvain MARECHAL wrote:
> Hello all,
>
> To avoid replication of some tables, I use a specific replication set.
> For example, with 2 nodes 'node1' and 'node2' and a table 'test' which
> content shall not be replicated, I do the following:
>
> mydb=# CREATE TABLE test (i INT PRIMARY KEY NOT NULL)
Oops!! My bad.. I did a reply and not a reply all...
Anyways Thanks David.. I knew this wasn't really a bug but could not figure
out where to post my questions. Let me just try the same in a different way
or do it differently as you explained and see if I can make it to work.
Thanks
On Tue, Sep
That is correct. But table old will NOT be converted to new because
only the schema name is converted. And table "old" WILL exist because it will
also be copied.
I have tested and it works properly.
Please do not provide hypothetical examples. Give me an actual working example
that causes the pr
I still do not see any problem. The whole purpose of the function is to copy
ALL sequences , tables and functions to "new" schema, so new.old WILL exist.
I don't see how you can possibly write a function that references a schema that
does not yet exist!
Again, please provide a _working_ example
On 2015-08-25 18:29, Craig Ringer wrote:
On 26 August 2015 at 07:19, Florin Andrei
wrote:
What do I need to do to start over? I want to delete all traces of the
BDR
configuration I've done so far.
you need to DROP the database you removed, then re-create it as a new
empty database. You can
On 2015-09-15 16:45, Florin Andrei wrote:
On 2015-08-25 18:29, Craig Ringer wrote:
On 26 August 2015 at 07:19, Florin Andrei
wrote:
What do I need to do to start over? I want to delete all traces of
the BDR
configuration I've done so far.
you need to DROP the database you removed, then re
20 matches
Mail list logo
