On 01/09/12 5:21 PM, Ron Somaraju wrote:
Once again, pros and cons should be left to users discretion because one may
have latest and greatest hardware and network resources. For example a SSD on a
fiber channel on a high speed network.
as I said before, when the checkpoint timeout goes off,
I'm still fumbling in the dark but I think I have a smell:
Does somebody know what supportsLobValueChangePropogation according to
the current JDBC specs?
There's an interesting note there:
> NOTE : I do not know the correct answer currently for databases which (1) are
> not part of the cruise co
CREATE FUNCTION uuid_generate_v1() RETURNS uuid AS '$libdir/uuid-ossp',
'uuid_generate_v1' VOLATILE STRICT LANGUAGE C;
I gоt error 'could not load library unknown error 14001' when i run this
script. What is this error and how can i rectify it? Postgres user has got full
access to postgresql fo
Once again, pros and cons should be left to users discretion because one may
have latest and greatest hardware and network resources. For example a SSD on a
fiber channel on a high speed network.
Regards,
rs
On Jan 9, 2012, at 7:06 PM, "Tom Lane" wrote:
> Scott Marlowe writes:
>> On Mon, Ja
>>> According to the manuals, Postgres has smallint (2 byte), integer (4
>>> bytes) and bigint (8 bytes).. I use a lot of structures with
>>> "bytes"
>>> in my code and it's kinda annoying to cast DB output from Int16 to
>>> Byte every time, especially sinc
On Tue, Jan 10, 2012 at 00:36, Mike Christensen wrote:
>> According to the manuals, Postgres has smallint (2 byte), integer (4
>> bytes) and bigint (8 bytes).. I use a lot of structures with "bytes"
>> in my code and it's kinda annoying to cast DB output from Int16 to
> According to the manuals, Postgres has smallint (2 byte), integer (4
> bytes) and bigint (8 bytes).. I use a lot of structures with "bytes"
> in my code and it's kinda annoying to cast DB output from Int16 to
> Byte every time, especially since there's no explicit
On Sun, Jan 8, 2012 at 21:31, Mike Christensen wrote:
> On Sun, Jan 8, 2012 at 10:12 AM, Francisco Figueiredo Jr.
> wrote:
>> On Sun, Jan 8, 2012 at 06:54, Mike Christensen wrote:
According to the manuals, Postgres has smallint (2 byte), integer (4
bytes) and bigint (8 bytes)..
Scott Marlowe writes:
> On Mon, Jan 9, 2012 at 4:58 PM, Tom Lane wrote:
>> There are tradeoffs in the other direction too, but if you feel you must
>> have a different value, see configure's --with-wal-segsize option. Note
>> that you cannot change this without re-initdb.
> Is there a limit to
On Mon, Jan 9, 2012 at 4:58 PM, Tom Lane wrote:
> rama writes:
>> Due to the small file size I see thousands of files being generated and it
>> takes for ever to list thousands of files from archive directory which
>> stores 2 days worth of files. Sizing of WAL logs should be left to the
>> choic
On Mon, Jan 9, 2012 at 1:06 PM, Scott Marlowe wrote:
> On Mon, Jan 9, 2012 at 12:37 PM, akp geek wrote:
>> I have statement_timeout as commented in the postgresql.conf. I just
>> checked it..
>
> statement timeout, like so many things, can be set per user or per
> database. Connect as the back
rama writes:
> Due to the small file size I see thousands of files being generated and it
> takes for ever to list thousands of files from archive directory which
> stores 2 days worth of files. Sizing of WAL logs should be left to the
> choice of people using the software. Limiting to a very smal
Hi,
On 10 January 2012 06:10, Jason Buberel wrote:
> "Select median price for every zip code as of 2012-01-06" (customer exports)
> "Select median price for 94086 from 2005-01-01 through 2012-01-06" (charting
> apps)
>
> So by partitioning in one dimension we impact queries in the other.
I do no
On 01/09/12 10:45 AM, rama wrote:
Due to the small file size I see thousands of files being generated and it
takes for ever to list thousands of files from archive directory which
stores 2 days worth of files. Sizing of WAL logs should be left to the
choice of people using the software. Limiting
Hi,
On 10 January 2012 09:16, Jason Buberel wrote:
> We have lots of them, they are much smaller than the tables, and that will
> allow us to do the migrations more incrementally.
In your case I would keep data and indexes on different table spaces
(and lower random_page_cost).
> One area where
Due to the small file size I see thousands of files being generated and it
takes for ever to list thousands of files from archive directory which
stores 2 days worth of files. Sizing of WAL logs should be left to the
choice of people using the software. Limiting to a very small random 16MB
size isn
As per Ondrej's suggestion, our current thinking/planning at this point is
to move indices instead of tables.
We have lots of them, they are much smaller than the tables, and that will
allow us to do the migrations more incrementally.
One area where the documentation is not very detailed - What a
On Mon, Jan 9, 2012 at 4:30 PM, Tom Lane wrote:
Sorry. Forgot to hit "Reply to All"
Aha. I think I'd gotten carried away with some of the settings in
order to optimize for bulk loading. Reverting back to the default
postgresql.conf gets me back to the sort of times you guys are seeing
here.
On 01/09/12 1:03 PM, Andy Chambers wrote:
I have an update that takes longer than expected and wondered if
there's an easy way to make it go faster.
It's pretty simple:-
create table session (
id serial primary key,
data text);
update session
set data = 'ipsum lorem...'
where id =
Andy Chambers writes:
> I have an update that takes longer than expected and wondered if
> there's an easy way to make it go faster.
> It's pretty simple:-
> create table session (
> id serial primary key,
> data text);
> update session
> set data = 'ipsum lorem...'
> where id = 5;
> T
In response to Andy Chambers :
>
> I have an update that takes longer than expected and wondered if
> there's an easy way to make it go faster.
>
> It's pretty simple:-
>
> create table session (
> id serial primary key,
> data text);
>
> update session
> set data = 'ipsum lorem...'
> w
Hi,
I have an update that takes longer than expected and wondered if
there's an easy way to make it go faster.
It's pretty simple:-
create table session (
id serial primary key,
data text);
update session
set data = 'ipsum lorem...'
where id = 5;
The "ipsum lorem.." stuff is an encrypt
On 10 January 2012 06:57, Radosław Smogura wrote:
> In real world BLOBs are transfered as references, and those references are
> managed in way as the trigger does. Nacked PG doesn't support deletion, Oid is
> universal type so it can't be used by GC approach, unles collector will know
> which Oi
On Mon, Jan 9, 2012 at 12:37 PM, akp geek wrote:
> I have statement_timeout as commented in the postgresql.conf. I just
> checked it..
statement timeout, like so many things, can be set per user or per
database. Connect as the backup use and issue this statement:
show statement_timeout;
--
I have the replication set up and I am running the pg_dump against the
master
Thanks
On Mon, Jan 9, 2012 at 2:33 PM, Adrian Klaver wrote:
> On Monday, January 09, 2012 11:16:46 am akp geek wrote:
> > I am using pg_dump to back up each schema in the database and there 6
> > schemas in the databa
I have statement_timeout as commented in the postgresql.conf. I just
checked it..
Thanks
On Mon, Jan 9, 2012 at 2:31 PM, Scott Marlowe wrote:
> On Mon, Jan 9, 2012 at 11:05 AM, akp geek wrote:
> > Hi All -
> >
> > During the backup of the database, we experience timeout
> on
>
On Monday, January 09, 2012 11:16:46 am akp geek wrote:
> I am using pg_dump to back up each schema in the database and there 6
> schemas in the database.
Do you have replication set up and if so are running the above against the
master or the standby?
>
> thanks
>
--
Adrian Klaver
adrian.kl
On 9 Jan 2012, at 18:57, Radosław Smogura wrote:
> In real world BLOBs are transfered as references, and those references are
> managed in way as the trigger does. Nacked PG doesn't support deletion, Oid
> is
> universal type so it can't be used by GC approach, unles collector will know
> whic
On Mon, Jan 9, 2012 at 11:05 AM, akp geek wrote:
> Hi All -
>
> During the backup of the database, we experience timeout on
> queries. any one has experienced the same? Is there any parameters in the
> postgressql.conf that I have to pay attention to? Can you please help
statement
I am using pg_dump to back up each schema in the database and there 6
schemas in the database.
thanks
On Mon, Jan 9, 2012 at 1:26 PM, Jerry Sievers wrote:
> akp geek writes:
>
> > Hi All -
> >
> > ? ? ? ? ? ? ? ? During the backup of the database, we experience
> > timeout on queries. any one h
Craig,
Good suggestion - I have experimented with table partitioning in the past,
but the impact on performance was considerable.
In our case, we have one large table with real estate statistics arranged
in time (weekly for the last five years) and geography (every zip in the
US). You could imagi
akp geek writes:
> Hi All -
>
> ? ? ? ? ? ? ? ? During the backup of the database, we experience
> timeout on queries. any one has experienced the same? Is there any
> parameters in the postgressql.conf that I have to pay attention to?
> Can you please help
What backup method and what statement
Hi All -
During the backup of the database, we experience timeout on
queries. any one has experienced the same? Is there any parameters in the
postgressql.conf that I have to pay attention to? Can you please help
Regards
Dnia poniedziałek, 9 stycznia 2012 o 15:52:23 Alban Hertroys napisał(a):
> On 9 January 2012 14:55, Radosław Smogura wrote:
> > So responsible for this is database, but database doesn't have
> > "real" BLOBs, this what is made in PG JDBC driver is just "not perfect"
> > way to add this functionali
Hi,
thats not a bug its a feature ;)
the combination hibernate/pgjdbc uses pg large objects for byte[] and
Blob properties so only oids are referenced. Use 'vacuumlo' to free up
your space.
regards
Thomas
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
On 9 January 2012 14:55, Radosław Smogura wrote:
> So responsible for this is database, but database doesn't have
> "real" BLOBs, this what is made in PG JDBC driver is just "not perfect" way
> to add this functionality to PostgreSQL.
I think you should elaborate on what you mean when you say tha
On Jan 9, 2012, at 5:07 AM, Alban Hertroys wrote:
> On 9 January 2012 09:56, Damiano ALBANI
>>> I believe DB2 is pretty much it in this area.
>>
>> For the record, it looks like MS SQL Server has some equivalent feature :
>> FILESTREAM.
>
> And Oracle has BFILE.
>
> I've actually been thinking
Dmitriy,
I have been building an executable c++ program that uses Postgresql C
(libpq) API. All SQL statements were designed to be executed in
non-blocking mode and it works fine with postgresql non-blocking interface.
I also wanted to handle blob files in non-blocking mode as well.
The size of t
On Fri, 06 Jan 2012 08:51:24 +0100, Guillaume Lelarge wrote:
On Fri, 2012-01-06 at 07:12 +0100, Stefan Keller wrote:
Hi Igor
2011/12/16 Igor Neyman wrote: > But I
think,
your problem is right here:
>
> " running VACUUM FULL pg_largeobject"
>
> If you are running "VACUUM FULL ..." on the tabl
On Mon, 9 Jan 2012 00:40:08 +0100, Stefan Keller wrote:
2012/1/8 Radosław Smogura wrote:
Not quite, PostgreSQL doesn't have LOB, nor OID type that is only
reference> to LOB. In fact, BLOB behaviour in JDBC> is just thin
wrapper for this what is missing in PostgreSQL - BLOBs.
I can't follow:
On 9 January 2012 12:36, John R Pierce wrote:
> On 01/09/12 3:07 AM, Alban Hertroys wrote:
>>>
>>> For the record, it looks like MS SQL Server has some equivalent feature :
>>> > FILESTREAM.
>>
>> And Oracle has BFILE.
>
> aren't these things functionally similar to PG's LO (large object) ?
Orac
On 10 January 2012 00:29, Oliver Jowett wrote:
> So I'm still confused about what you'd like to see changed in the JDBC
> driver. Can you explain?
Perhaps what you're looking for here is "it all just works out of the
box". In that case, the missing piece seems to be that the DDL that
Hibernate e
On 01/09/12 3:07 AM, Alban Hertroys wrote:
For the record, it looks like MS SQL Server has some equivalent feature :
> FILESTREAM.
And Oracle has BFILE.
aren't these things functionally similar to PG's LO (large object) ?
--
john r pierceN 37, W 122
santa cruz c
On 10 January 2012 00:06, Stefan Keller wrote:
> 2012/1/9 Oliver Jowett :
>> Otherwise, what should JDBC do differently here? Be specific. It would
>
> First, I pretty sure that Hibernate nor the Tomcat/Java GC are
> misconfigured - since it works now after having installed the trigger
> by hand.
On 9 January 2012 09:56, Damiano ALBANI
>> I believe DB2 is pretty much it in this area.
>
> For the record, it looks like MS SQL Server has some equivalent feature :
> FILESTREAM.
And Oracle has BFILE.
I've actually been thinking about how to implement something like this
for Postgres, but the i
2012/1/9 Oliver Jowett :
> Otherwise, what should JDBC do differently here? Be specific. It would
First, I pretty sure that Hibernate nor the Tomcat/Java GC are
misconfigured - since it works now after having installed the trigger
by hand.
To become more specific read the first two sections as a
On Mon, Jan 9, 2012 at 9:53 AM, Jon Nelson wrote:
> On Sun, Jan 8, 2012 at 7:13 PM, 邓尧 wrote:
> > I have enabled the autocommit feature of psycopg2, and removed all the
> > transactions in source code, also changed the sql statement to the
> > following:
> >
> > insert into ACCOUNT(HOME)
> >
On Sun, Jan 8, 2012 at 21:13, Peter Eisentraut wrote:
>
> I'm not aware of any plans. What would be your use case?
>
Well, basically what DATALINK is made for: storing files in the filesystem
and only keeping the reference in the database.
What I'm most interested in are the "transaction" and "
48 matches
Mail list logo
