On Wed, Mar 22, 2017 at 3:27 AM, Rakesh Kumar
wrote:
> PG does not have a concept of incremental backup. The way it works in
> Oracle and other RDBMS is that incremental backup only backups up changed
> blocks since the last full backup. So if only 10% of blocks changed since
> the last full ba
John,
* John R Pierce (pie...@hogranch.com) wrote:
> On 3/21/2017 5:27 PM, Rakesh Kumar wrote:
> >PG does not have a concept of incremental backup. The way it works in
> >Oracle and other RDBMS is that incremental backup only backups up changed
> >blocks since the last full backup. So if only
Greetings,
* Rakesh Kumar (rakeshkumar...@outlook.com) wrote:
> PG does not have a concept of incremental backup. The way it works in Oracle
> and other RDBMS is that incremental backup only backups up changed blocks
> since the last full backup. So if only 10% of blocks changed since the last
On 3/21/2017 5:27 PM, Rakesh Kumar wrote:
PG does not have a concept of incremental backup. The way it works in Oracle
and other RDBMS is that incremental backup only backups up changed blocks since
the last full backup. So if only 10% of blocks changed since the last full
backup, incrementa
On 03/21/2017 05:27 PM, Rakesh Kumar wrote:
PG does not have a concept of incremental backup. The way it works in Oracle
and other RDBMS is that incremental backup only backups up changed blocks since
the last full backup. So if only 10% of blocks changed since the last full
backup, incremen
PG does not have a concept of incremental backup. The way it works in Oracle
and other RDBMS is that incremental backup only backups up changed blocks since
the last full backup. So if only 10% of blocks changed since the last full
backup, incremental backup will be only for 10%.
I am wonderin
On 03/21/2017 03:03 PM, Tom Ekberg wrote:
I have been working with MySQL a bit (yes, I know, heresy) and
encountered a program called mysql_config_editor. In my opinion it does
a better job of local password management than using a ~/.pgpass file.
Instead of assuming that a mode of 600 will keep
On 03/21/2017 04:27 PM, DrakoRod wrote:
Hi folks!
I've a query with a join of two tables. One table have a 5 millions rows and
child table have a 17 millions rows. The query is executed many times in
application, every 20 seconds aproximately.
The query normally execute in 2-3 seconds but in so
Hi folks!
I've a query with a join of two tables. One table have a 5 millions rows and
child table have a 17 millions rows. The query is executed many times in
application, every 20 seconds aproximately.
The query normally execute in 2-3 seconds but in some time without apparent
pattern the quer
> On Mar 21, 2017, at 3:03 PM, Tom Ekberg wrote:
>
> I have been working with MySQL a bit (yes, I know, heresy) and encountered a
> program called mysql_config_editor. In my opinion it does a better job of
> local password management than using a ~/.pgpass file. Instead of assuming
> that a m
2017-03-21 23:03 GMT+01:00 Tom Ekberg :
> I have been working with MySQL a bit (yes, I know, heresy) and encountered
> a program called mysql_config_editor. In my opinion it does a better job of
> local password management than using a ~/.pgpass file. Instead of assuming
> that a mode of 600 will
Given a country table and an order table:
CREATE TABLE g.country
(
-- inherited from table g.standard: oid uuid NOT NULL,
-- ... some more columns inherited...
lisocode integer NOT NULL, -- Numeric ISO 3166 code
szisoalpha2 character varying(2), -- The 2 letter country code
szisoalpha3 char
I have been working with MySQL a bit (yes, I know, heresy) and encountered a
program called mysql_config_editor. In my opinion it does a better job of local
password management than using a ~/.pgpass file. Instead of assuming that a
mode of 600 will keep people from peeking at your password, it
On Tue, Mar 21, 2017 at 1:45 PM, Adrian Klaver
wrote:
> On 03/21/2017 12:11 PM, Alexander Farber wrote:
>
>> Thank you - this has worked:
>>
>> COPY words_reviews (uid, author, nice, review, updated) FROM stdin WITH
>> (FORMAT csv);
>> 1,2,1,'1 is nice by 2','2017-03-01'
>> 1,3,1,'1 is nice by 3'
On 03/21/2017 12:11 PM, Alexander Farber wrote:
Thank you - this has worked:
COPY words_reviews (uid, author, nice, review, updated) FROM stdin WITH
(FORMAT csv);
1,2,1,'1 is nice by 2','2017-03-01'
1,3,1,'1 is nice by 3','2017-03-02'
1,4,1,'1 is nice by 4','2017-03-03'
2,1,1,'2 is nice by 1','2
On Tue, Mar 21, 2017 at 12:45 PM, Paul Jungwirth <
p...@illuminatedcomputing.com> wrote:
> On 03/21/2017 12:21 PM, David G. Johnston wrote:
>
>> > words=> COPY words_reviews (uid, author, nice, review, updated) FROM
>> > stdin FORMAT csv;
>>
>> What did you read that lead you to think the abov
On 03/21/2017 12:21 PM, David G. Johnston wrote:
> words=> COPY words_reviews (uid, author, nice, review, updated) FROM
> stdin FORMAT csv;
What did you read that lead you to think the above shoud work?
I don't know about COPY FROM, but COPY TO works without parens (or
FORMAT), like this:
On Tuesday, March 21, 2017, Alexander Farber
wrote:
>
> words=> COPY words_reviews (uid, author, nice, review, updated) FROM stdin
> FORMAT csv;
>
What did you read that lead you to think the above shoud work?
David J.
Thank you - this has worked:
COPY words_reviews (uid, author, nice, review, updated) FROM stdin WITH
(FORMAT csv);
1,2,1,'1 is nice by 2','2017-03-01'
1,3,1,'1 is nice by 3','2017-03-02'
1,4,1,'1 is nice by 4','2017-03-03'
2,1,1,'2 is nice by 1','2017-03-01'
2,3,1,'2 is nice by 3','2017-03-02'
2,4
Alexander:
On Tue, Mar 21, 2017 at 6:31 PM, Alexander Farber
wrote:
> I keep rereading https://www.postgresql.org/docs/9.6/static/sql-copy.html
> but just can't figure the proper syntax to put some records into the table:
It's not that complex, let's see
> words=> COPY words_reviews (uid, a
On 3/21/2017 10:31 AM, Alexander Farber wrote:
words=> COPY words_reviews (uid, author, nice, review, updated) FROM
stdin WITH FORMAT 'csv';
ERROR: syntax error at or near "FORMAT"
LINE 1: ...d, author, nice, review, updated) FROM stdin WITH FORMAT 'cs...
its just csv, not 'csv' ...
And I h
On Tue, Mar 21, 2017 at 10:31 AM, Alexander Farber <
alexander.far...@gmail.com> wrote:
> Good evening,
>
> I keep rereading https://www.postgresql.org/docs/9.6/static/sql-copy.html
> but just can't figure the proper syntax to put some records into the table:
> [...]
>
> words=> COPY words_revie
Good evening,
I keep rereading https://www.postgresql.org/docs/9.6/static/sql-copy.html
but just can't figure the proper syntax to put some records into the table:
words=> \d words_reviews;
Table "public.words_reviews"
Column | Type | Modifiers
-+--
I played around with COST up to 99 – still no improvement.
HOWEVER – I determined that more than 95% of the records in the database are
local addresses and the indexed function returns NULL.
This seems to create an issue with LEFT JOIN.
Increasing the COST of the function to 2
On 03/21/2017 07:42 AM, Tom Lane wrote:
Frazer McLean writes:
I came across an unexpected comparison (tested on PostgreSQL 9.4 and
9.6) for intervals with a large difference in magnitude.
'1 year'::interval > '32618665 years'::interval;
Is this a bug?
It looks like the problem is over
Frazer McLean writes:
> I came across an unexpected comparison (tested on PostgreSQL 9.4 and
> 9.6) for intervals with a large difference in magnitude.
> '1 year'::interval > '32618665 years'::interval;
> Is this a bug?
It looks like the problem is overflow of the result of interval_cmp_value
I came across an unexpected comparison (tested on PostgreSQL 9.4 and
9.6) for intervals with a large difference in magnitude.
I narrowed it down to this example, where comparisons with this range
give the wrong value:
postgres=# SELECT
'1 year'::interval > '3854933 years'::interval,
'1 y
27 matches
Mail list logo
