Re: [GENERAL] High load average every 105 minutes

[Nhan Nguyen]

Thanks for the reply.
I found no strange processes or queries while load average was at peak. IO also 
didn't change. Some more slow queries were logged, but not many.
I think sharing the VM with other customers doesn’t have much to do with this. 
I checked my other servers too, and only those that have postgresql have the 
load average issue. Generally it doesn’t impact my system much, but when there 
are slow queries, this issue just makes everything worse.

Nhan Nguyen
System Engineer

MB: (+84) 934 008 031
Skype: live:ducnhan813

> On Nov 4, 2016, at 4:03 PM, John R Pierce  wrote:
> 
> On 11/4/2016 1:45 AM, Nhan Nguyen wrote:
>> 
>> The load average of the instance increase every 105 minutes even without any 
>> database. I’ve checked the scheduled jobs but couldn’t find anything 
>> suspicious. When the load average was at peak, I couldn’t see any process 
>> consuming resources. This happens on all my servers that has postgresql 
>> installed, even after I purge postgresql. Has anyone seen this before
> 
> load average doesn't mean much other than the number of processes waiting for 
> a resource.   does the IO latency spike at this time, too?
> 
> with AWS, your system is sharing the vendors virtual machine environment with 
> other customers, and performance is pretty much out of your control.
> 
> -- 
> john r pierce, recycling bits in santa cruz
> 
> 
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Exclude pg_largeobject form pg_dump

[amul sul]

On Mon, Nov 7, 2016 at 2:03 AM, Guillaume Lelarge
 wrote:
>>
>> Agreed. I was afraid of that, but for some reason, didn't find that. I'll
>> fix this.
>
>
> Fixed in v4.
>

This fix is broken.

 70  -   if (dopt.include_everything && !dopt.schemaOnly)
 71 +   if (dopt.include_everything && !dopt.schemaOnly && !dopt.outputBlobs)
 72 dopt.outputBlobs = true;

dopt.outputBlobs set to FALSE when option -B is specified and this IF
condition reverts to TRUE which force to dump blobs.

>>
>>
>>>
>>> #2 :
>>> We should add note for default behaviour if --no-blobs & --blobs both
>>> are specified.
>>>
>>
>> Right. I don't know how I will handle this, but you're right that the
>> behaviour should be specified. I'll also fix this.
>>
>
> I checked other options, such as --format, and there's nothing noted as a
> default behaviour. Last one wins, which is what this patch does.
>

Such note exists for --table & --exclude-table option, see following
lines in pg_dump.sgml

 569
 570 When both -t and -T are given, the behavior
 571 is to dump just the tables that match at least one -t
 572 switch but no -T switches.  If -T appears
 573 without -t, then tables matching -T are
 574 excluded from what is otherwise a normal dump.
 575
 576   

Regards,
Amul Sul


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Dynamic execution returning large result sets

[Adrian Klaver]

On 11/06/2016 05:12 PM, Emrul wrote:

Hi,

I have a function that returns an SQL string as follows:
CREATE OR REPLACE FUNCTION t1() RETURNS text AS
$$
BEGIN
RETURN 'SELECT * FROM mytable';
END
$$ LANGUAGE plpgsql;

and I want to create a second function (t2) that will execute the string
returned by t1() and return the results.  I thought about using RETURN QUERY
EXECUTE as documented here:
https://www.postgresql.org/docs/9.6/static/plpgsql-control-structures.html
but there's a note towards the end that says '/if a PL/pgSQL function
produces a very large result set, performance might be poor: data will be
written to disk to avoid memory exhaustion, but the function itself will not
return until the entire result set has been generated./'

Is there any other way I can achieve execution of the dynamic SQL from t1()
without having the whole result set retrieved inside the function itself?


https://www.postgresql.org/docs/9.5/static/plpgsql-cursors.html

"Rather than executing a whole query at once, it is possible to set up a 
cursor that encapsulates the query, and then read the query result a few 
rows at a time. One reason for doing this is to avoid memory overrun 
when the result contains a large number of rows. (However, PL/pgSQL 
users do not normally need to worry about that, since FOR loops 
automatically use a cursor internally to avoid memory problems.) A more 
interesting usage is to return a reference to a cursor that a function 
has created, allowing the caller to read the rows. This provides an 
efficient way to return large row sets from functions."




note: My example above is simplified, my real t1() function takes some
parameters and generates SQL depending upon those parameters.


Thanks!



--
View this message in context: 
http://postgresql.nabble.com/Dynamic-execution-returning-large-result-sets-tp5929177.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.





--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Dynamic execution returning large result sets

[Emrul]

Hi,

I have a function that returns an SQL string as follows:
CREATE OR REPLACE FUNCTION t1() RETURNS text AS
$$
BEGIN
RETURN 'SELECT * FROM mytable';
END
$$ LANGUAGE plpgsql;

and I want to create a second function (t2) that will execute the string
returned by t1() and return the results.  I thought about using RETURN QUERY
EXECUTE as documented here:
https://www.postgresql.org/docs/9.6/static/plpgsql-control-structures.html
but there's a note towards the end that says '/if a PL/pgSQL function
produces a very large result set, performance might be poor: data will be
written to disk to avoid memory exhaustion, but the function itself will not
return until the entire result set has been generated./'

Is there any other way I can achieve execution of the dynamic SQL from t1()
without having the whole result set retrieved inside the function itself?

note: My example above is simplified, my real t1() function takes some
parameters and generates SQL depending upon those parameters.


Thanks!



--
View this message in context: 
http://postgresql.nabble.com/Dynamic-execution-returning-large-result-sets-tp5929177.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Exclude pg_largeobject form pg_dump

[Guillaume Lelarge]

2016-11-04 9:35 GMT+01:00 Guillaume Lelarge :

> Hi Amul,
>
> 2016-11-04 7:52 GMT+01:00 amul sul :
>
>> Hi Guillaume,
>>
>> I found following issues with this patch, sorry missed in previous post:
>>
>>
> You don't have to be sorry for me doing shitty things :)
>
>
>> #1 :
>>  43 @@ -392,6 +393,10 @@ main(int argc, char **argv)
>>  44 dopt.outputBlobs = true;
>>  45 break;
>>  46
>>  47 +   case 'B':   /* Don't dump blobs */
>>  48 +   dopt.include_everything = false;
>>  49 +   break;
>>  50 +
>>
>> Touching dopt.include_everything flag does not seems to be a good idea
>> for '--no-blobs' option, our intension is to exclude blob only, but
>> this excluds other dump too (e.g COMMENT ON DATABASE, CREATE
>> EXTENSION, COMMENT ON EXTENSION, .., etc)  that what we don't want,
>> right?
>>
>>
> Agreed. I was afraid of that, but for some reason, didn't find that. I'll
> fix this.
>

Fixed in v4.


>
>
>> #2 :
>> We should add note for default behaviour if --no-blobs & --blobs both
>> are specified.
>>
>>
> Right. I don't know how I will handle this, but you're right that the
> behaviour should be specified. I'll also fix this.
>
>
I checked other options, such as --format, and there's nothing noted as a
default behaviour. Last one wins, which is what this patch does.


> I'll try to work on this today but as I'm in pgconf.eu 2016, it may be
> only for tomorrow.
>
>
It tooks me more time than expected. v4 attached.

>

-- 
Guillaume.
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 371a614..83dc52f 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -145,6 +145,16 @@ PostgreSQL documentation
  
 
  
+  -B
+  --no-blobs
+  
+   
+Exclude large objects in the dump.
+   
+  
+ 
+
+ 
   -c
   --clean
   
diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c
index 0e20985..f90c074 100644
--- a/src/bin/pg_dump/pg_backup_archiver.c
+++ b/src/bin/pg_dump/pg_backup_archiver.c
@@ -137,6 +137,7 @@ InitDumpOptions(DumpOptions *opts)
 {
 	memset(opts, 0, sizeof(DumpOptions));
 	/* set any fields that shouldn't default to zeroes */
+	opts->outputBlobs = true;
 	opts->include_everything = true;
 	opts->dumpSections = DUMP_UNSECTIONED;
 }
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 4da297f..4d3e245 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -291,6 +291,7 @@ main(int argc, char **argv)
 	static struct option long_options[] = {
 		{"data-only", no_argument, NULL, 'a'},
 		{"blobs", no_argument, NULL, 'b'},
+		{"no-blobs", no_argument, NULL, 'B'},
 		{"clean", no_argument, NULL, 'c'},
 		{"create", no_argument, NULL, 'C'},
 		{"dbname", required_argument, NULL, 'd'},
@@ -379,7 +380,7 @@ main(int argc, char **argv)
 
 	InitDumpOptions();
 
-	while ((c = getopt_long(argc, argv, "abcCd:E:f:F:h:j:n:N:oOp:RsS:t:T:U:vwWxZ:",
+	while ((c = getopt_long(argc, argv, "abBcCd:E:f:F:h:j:n:N:oOp:RsS:t:T:U:vwWxZ:",
 			long_options, )) != -1)
 	{
 		switch (c)
@@ -392,6 +393,10 @@ main(int argc, char **argv)
 dopt.outputBlobs = true;
 break;
 
+			case 'B':			/* Don't dump blobs */
+dopt.outputBlobs = false;
+break;
+
 			case 'c':			/* clean (i.e., drop) schema prior to create */
 dopt.outputClean = 1;
 break;
@@ -708,7 +713,7 @@ main(int argc, char **argv)
 	 * Dumping blobs is now default unless we saw an inclusion switch or -s
 	 * ... but even if we did see one of these, -b turns it back on.
 	 */
-	if (dopt.include_everything && !dopt.schemaOnly)
+	if (dopt.include_everything && !dopt.schemaOnly && !dopt.outputBlobs)
 		dopt.outputBlobs = true;
 
 	/*
@@ -864,6 +869,7 @@ help(const char *progname)
 	printf(_("\nOptions controlling the output content:\n"));
 	printf(_("  -a, --data-only  dump only the data, not the schema\n"));
 	printf(_("  -b, --blobs  include large objects in dump\n"));
+	printf(_("  -B, --no-blobs   exclude large objects in dump\n"));
 	printf(_("  -c, --clean  clean (drop) database objects before recreating\n"));
 	printf(_("  -C, --create include commands to create database in dump\n"));
 	printf(_("  -E, --encoding=ENCODING  dump the data in encoding ENCODING\n"));

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] timestamp without timezone to have timezone

[Adrian Klaver]

On 11/06/2016 09:24 AM, Benjamin Adams wrote:

Please Reply to list also.
I have Cced list

> On Nov 6, 2016 11:07 AM, "Adrian Klaver"  > wrote:
>>
>> On 11/06/2016 06:11 AM, Benjamin Adams wrote:
>> > I have a server that has a column timestamp without timezone.
>> >
>> > Is the time still saved?
>>
>> Yes the timestamp is always saved. What that timestamp is differs:
>>
>> test[5432]=# create table ts_tsz_test(fld_1 timestamp, fld_2 timestamp
> with time zone);
>> CREATE TABLE
>>
>> test[5432]=# insert into ts_tsz_test values (now(), now());
>> INSERT 0 1
>>
>> test[5432]=# select * from ts_tsz_test ;
>>fld_1| fld_2
>> +---
>>  2016-11-06 07:52:01.053218 | 2016-11-06 07:52:01.053218-08
>>
>>
>> As you can see the timestamp field is a naive value, it has no concept
> of timezone and
>> assumes local time. The timestamp with time zone is time zone aware,
> in this case displaying
>> as my local time also with the appropriate offset. The reason being
> that timestamp with time
>> zone is stored as UTC and converted on display. To learn more see the
> below:
>>
>> https://www.postgresql.org/docs/9.5/static/datatype-datetime.html
>> 8.5.1.3. Time Stamps
>>
>> > if I select column with timestamp it will show server timestamp with
>> > timezone.
>>
>> Correct.
>>
>> >
>> > But If I move the data from EST to Central will the timestamp with
>> > timezone be correct?
>>
>> Are you moving the data or the server or both?
> 
> Just moving data. Server will have new local time.

If I am following correctly you will be changing the TimeZone setting from EST 
to Central, correct?

So for practical purposes both, in that the moved data will have naive 
timestamp data in 
a 'new' timezone from its point of view

> 
>>
>> In other words can you be more specific about what moving the data means?
>>
>> If you are not moving the server(eg retaining the TimeZome config)
> then the timestamp(w/o tz)
>> will be displaying in EST not Central. Postgres has no internal way of
> knowing
>> what the timestamp(w/o tz) data values are anchored to. This leads to
> another question.
>>
>> Did all the current values originate from EST?
> 
> All current are est.  If I do select at UTC. Will data respond with same
> time after moving data?

Well first are the values actually all derived from EST or are they a mix of 
EST/EDT? I suspect the latter.

As to your question, maybe:

https://www.postgresql.org/docs/9.5/static/datatype-datetime.html#DATATYPE-TIMEZONES

8.5.1.3. Time Stamps

"Conversions between timestamp without time zone and timestamp with time zone 
normally assume 
that the timestamp without time zone value should be taken or given as timezone 
local time. 
A different time zone can be specified for the conversion using AT TIME ZONE."

To continue my previous example and given that this morning was the DST --> 
Standard Time transition. Also
that I am in Pacific time zones:

test[5432]=# insert into ts_tsz_test values ('2016-11-05 07:52:01.053218' , 
'2016-11-05 07:52:01.053218');
INSERT 0 1
test[5432]=# select * from ts_tsz_test ;
   fld_1| fld_2 
+---
 2016-11-06 07:52:01.053218 | 2016-11-06 07:52:01.053218-08
 2016-11-05 07:52:01.053218 | 2016-11-05 07:52:01.053218-07


test[5432]=# select fld_1, fld_1 at time zone 'utc', fld_2, fld_2 at time zone 
'utc' from ts_tsz_test;   
   fld_1|   timezone| fld_2 
|  timezone  
+---+---+
 2016-11-06 07:52:01.053218 | 2016-11-06 00:52:01.053218-07 | 2016-11-06 
07:52:01.053218-08 | 2016-11-06 15:52:01.053218
 2016-11-05 07:52:01.053218 | 2016-11-05 00:52:01.053218-07 | 2016-11-05 
07:52:01.053218-07 | 2016-11-05 14:52:01.053218

test[5432]=# select fld_1, fld_1 at time zone 'America/Los_Angeles', fld_2, 
fld_2 at time zone 'utc' from ts_tsz_test;
   fld_1|   timezone| fld_2 
|  timezone  
+---+---+
 2016-11-06 07:52:01.053218 | 2016-11-06 07:52:01.053218-08 | 2016-11-06 
07:52:01.053218-08 | 2016-11-06 15:52:01.053218
 2016-11-05 07:52:01.053218 | 2016-11-05 07:52:01.053218-07 | 2016-11-05 
07:52:01.053218-07 | 2016-11-05 14:52:01.053218


test[5432]=# select fld_1, fld_1 at time zone 'America/Los_Angeles' at time 
zone 'UTC', fld_2, fld_2 at time zone 'utc' from ts_tsz_test;
   fld_1|  timezone  | fld_2
 |  

Re: [GENERAL] timestamp without timezone to have timezone

[Steve Crawford]

On Sun, Nov 6, 2016 at 7:10 AM, Melvin Davidson 
wrote:
>
>
>
> On Sun, Nov 6, 2016 at 9:11 AM, Benjamin Adams 
wrote:
>>
>> I have a server that has a column timestamp without timezone.
>>
>> Is the time still saved?
>> if I select column with timestamp it will show server timestamp with
timezone.
>>
>> But If I move the data from EST to Central will the timestamp with
timezone be correct?
>> Or will it just not make the adjustment?
>>
>> Thanks
>> Ben
>
>
> >But If I move the data from EST to Central will the timestamp with
timezone be correct?
>
> The correct way to do that is to use the  AT TIME ZONE function.
>
>
https://www.postgresql.org/docs/9.4/static/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT
>
> eg:
>
> postgres=> SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'EST' as
Eastern,
> postgres->TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'CST' as
Central,
> postgres->TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'MST' as
Mountain,
> postgres->TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'PST' as
Pacific;
> eastern |central |mountain
 |pacific
>
+++
>  2001-02-16 20:38:40-05 | 2001-02-16 21:38:40-05 | 2001-02-16 22:38:40-05
| 2001-02-16 23:38:40-05
> (1 row)


The question does not completely make sense and Melvin's answer is headed
in the right direction but there are a number of subtleties and
complications.

First, let me rephrase to make sure I understand the question. You have
some table(s) with column(s) of type timestamp without time zone. You
currently view the data from the perspective of US/Eastern (probably not
actually EST - more comments on the difference between offsets and zones
below) and want to know what happens if you view it from the perspective of
US/Central.

The short answer is that nothing will change. I'm in US/Pacific by default:

steve=> create temporary table foo (bar timestamp without time zone);
CREATE TABLE
steve=> insert into foo values (now());
INSERT 0 1

steve=> select bar from foo;
   bar

2016-11-06 08:57:06.808096

steve=> set timezone to 'US/Eastern';

steve=> select bar from foo;
   bar

2016-11-06 08:57:06.808096

steve=> set timezone to 'US/Central';

steve=> select bar from foo;
   bar

2016-11-06 08:57:06.808096


But if you do any sort of operation for which the timestamp alone is not
sufficient thus time zone information is required, PostgreSQL will
convert/calculate based on the current time zone setting.

Starting back at Pacific time, if I look at various other time zones I get:
steve=> select
   bar at time zone 'US/Pacific',
   bar at time zone 'US/Central',
   bar at time zone 'US/Eastern'
from
   foo;
-[ RECORD 1 ]---
timezone | 2016-11-06 08:57:06.808096-08
timezone | 2016-11-06 06:57:06.808096-08
timezone | 2016-11-06 05:57:06.808096-08

But if my client is set to Eastern I get:

steve=> set time zone 'US/Eastern';

steve=> select
   bar at time zone 'US/Pacific',
   bar at time zone 'US/Central',
   bar at time zone 'US/Eastern'
from
   foo;
-[ RECORD 1 ]---
timezone | 2016-11-06 11:57:06.808096-05
timezone | 2016-11-06 09:57:06.808096-05
timezone | 2016-11-06 08:57:06.808096-05

If you alter the table and change the data type to timestamp with time zone
(which to my mind is a bad name that we are stuck with - it should be
thought of as a "point in time" that can be displayed in any local time
zone) the data will be converted as above based on the current time zone
setting.

Another "gotcha": "EST" is an *offset* from UTC - specifically, it is
5-hours behind UTC. "US/Eastern", or one of the equivalent full names for
that zone (select * from pg_timezone_names;), is a time *zone*. Time zones
incorporate the various spring-forward/fall-back offset rules as they have
changed through history. Today is a convenient day for demonstrating. I
changed the table to have two columns, bar1 and bar2. bar2 has the
timestamp we used before and bar1 is the same timestamp but a day earlier.
This is what you will get if you display the values and the difference
between them in a zone-unaware way:

steve=> select bar1, bar2, bar2-bar1 from foo;
-[ RECORD 1 ]
bar1 | 2016-11-05 08:57:06.808096
bar2 | 2016-11-06 08:57:06.808096
?column? | 1 day

Now, let's change the data types (I'm still set to US/Eastern):

steve=> alter table foo alter column bar1 type timestamp with time zone;

steve=> alter table foo alter column bar2 type timestamp with time zone;

steve=> select bar1, bar2, bar2-bar1 from foo;
-[ RECORD 1 ]---
bar1 | 2016-11-05 08:57:06.808096-04
bar2 | 2016-11-06 08:57:06.808096-05
?column? | 1 day 01:00:00

Note 

Re: [GENERAL] timestamp without timezone to have timezone

[Adrian Klaver]

On 11/06/2016 06:11 AM, Benjamin Adams wrote:
> I have a server that has a column timestamp without timezone.
> 
> Is the time still saved?

Yes the timestamp is always saved. What that timestamp is differs:

test[5432]=# create table ts_tsz_test(fld_1 timestamp, fld_2 timestamp with 
time zone); 
 
CREATE TABLE

 
test[5432]=# insert into ts_tsz_test values (now(), now());
INSERT 0 1

test[5432]=# select * from ts_tsz_test ;
   fld_1| fld_2 
+---
 2016-11-06 07:52:01.053218 | 2016-11-06 07:52:01.053218-08


As you can see the timestamp field is a naive value, it has no concept of 
timezone and 
assumes local time. The timestamp with time zone is time zone aware, in this 
case displaying
as my local time also with the appropriate offset. The reason being that 
timestamp with time
zone is stored as UTC and converted on display. To learn more see the below:

https://www.postgresql.org/docs/9.5/static/datatype-datetime.html
8.5.1.3. Time Stamps

> if I select column with timestamp it will show server timestamp with
> timezone.

Correct.

> 
> But If I move the data from EST to Central will the timestamp with
> timezone be correct?

Are you moving the data or the server or both?

In other words can you be more specific about what moving the data means?

If you are not moving the server(eg retaining the TimeZome config) then the 
timestamp(w/o tz) 
will be displaying in EST not Central. Postgres has no internal way of knowing
what the timestamp(w/o tz) data values are anchored to. This leads to another 
question.

Did all the current values originate from EST?

> Or will it just not make the adjustment?

See above. 
> 
> Thanks
> Ben


-- 
Adrian Klaver
adrian.kla...@aklaver.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] timestamp without timezone to have timezone

[Melvin Davidson]

On Sun, Nov 6, 2016 at 9:11 AM, Benjamin Adams 
wrote:

> I have a server that has a column timestamp without timezone.
>
> Is the time still saved?
> if I select column with timestamp it will show server timestamp with
> timezone.
>
> But If I move the data from EST to Central will the timestamp with
> timezone be correct?
> Or will it just not make the adjustment?
>
> Thanks
> Ben
>







*>But If I move the data from EST to Central will the timestamp with
timezone be correct?The correct way to do that is to use the  AT TIME ZONE
function.https://www.postgresql.org/docs/9.4/static/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT
*

*eg:*








*postgres=> SELECT TIMESTAMP '2001-02-16 20:38:40' AT TIME ZONE 'EST'
as Eastern,postgres->TIMESTAMP '2001-02-16 20:38:40' AT TIME
ZONE 'CST' as Central,postgres->TIMESTAMP '2001-02-16
20:38:40' AT TIME ZONE 'MST' as Mountain,postgres->TIMESTAMP
'2001-02-16 20:38:40' AT TIME ZONE 'PST' as Pacific;eastern
 |central |mountain|
pacific+++
2001-02-16 20:38:40-05 | 2001-02-16 21:38:40-05 | 2001-02-16
22:38:40-05 | 2001-02-16 23:38:40-05(1 row)
*

*-- *
*Melvin Davidson*
I reserve the right to fantasize.  Whether or not you
wish to share my fantasy is entirely up to you.

[GENERAL] timestamp without timezone to have timezone

[Benjamin Adams]

I have a server that has a column timestamp without timezone.

Is the time still saved?
if I select column with timestamp it will show server timestamp with
timezone.

But If I move the data from EST to Central will the timestamp with timezone
be correct?
Or will it just not make the adjustment?

Thanks
Ben

[GENERAL] Parallel pg_dump/restore and LOs

[Andreas Joseph Krogh]

Hi all.
 
When dumping large-objects it doesn't appear that it's done in parallel, 
meaning only one thread for dumping all LOs. Is this the case?
When pg_dump comes to dumping large-objects it outputs (when -v is specified):
pg_dump: saving large objects
 Then it seems only 1 CPU is working.
 
Are there some plans to make dumping large tables (typically LOs) benefit from 
parallelism?
 
Thanks.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andr...@visena.com 
www.visena.com