On Wed, 2009-02-18 at 12:55 -0800, Mike Christensen wrote:
I have well over 50 gigs free on that drive.. I doubt it.
Are you sure the pg data directory is on the drive you think it is? Are
you doing alot of deletes or are you merely inserting? Are you doing
any sorting and therefore running
On Tue, 2009-02-17 at 17:17 +0100, Marco Colombo wrote:
Which makes me wonder, does copy accept UTF-8 input? Is it possibile
to use some unicode character which is unlikely to appear in the data
set as delimiter? Something like U+FFFC.
I'm also not able to get unicode characters to copy in
On Thu, 2009-02-12 at 12:51 -0800, SHARMILA JOTHIRAJAH wrote:
My data fields contains commas, tabs,'|' etc. So I cant use t hem as
delimiters..so I need a unique may be non-character to use as a
delimiter...
-Sharmila
Is this a theoretical problem or an actual one? I haven't had any
On Thu, 2009-01-29 at 13:16 +, Gregory Stark wrote:
I'm putting together a talk on PostgreSQL Pet Peeves for discussion at
FOSDEM 2009 this year. I have a pretty good idea what some them are of course,
but I would be interested to hear if people have any complaints from personal
On Tue, 2008-12-02 at 10:40 +, Grzegorz Jaśkiewicz wrote:
but than you have to add cost of backing up and restoring labour time,
and that's going to be a massive latency - if you ask me.
Of course it is, but really latency probably isn't the key issue - more
that the data itself isn't
My problem is, I need to benchmark set of tables, where - we can
assume - schema of each table is unknown, and we have no assumption on
any fields being present there. (altho, if there is no other way to do
it, we could assume id bigint not null default nextval('someseq'));
basically, I
On Thu, 2008-08-21 at 13:53 -0600, Scott Marlowe wrote:
Regular SERIAL type is limited to a 32 bit int. BIGSERIAL uses a 64
bit int.
I think one of the things that would be offsetting is the size
difference between the two types (32 vs 64 bits, 5 foreign keys, and a
billion rows or so makes
On Mon, 2008-08-25 at 11:02 -0600, Scott Marlowe wrote:
Well, of course a 64 bit int is gonna be bigger than a 32 bit, but
with alignment issues and on 64 bit hardware, I'm guessing the
difference isn't exactly twice as slow / twice as much storage. And
it's way faster than a GUID which was
On Thu, 2008-08-21 at 22:17 +0800, Amber wrote:
Another question, how many people are there maintaining this huge database.
We have about 2T of compressed SAS datasets, and now considering load them
into a RDBMS database,
according to your experience, it seems a single PostgreSQL instance
Just out of curiosity, how do you replicate that amount of data?
When I started working here, we used Slony-I to replicate our aggregate
fact tables. A little over a year ago our data volume had grown to the
point that the Slony was regularly unable to keep up with the data
volume and around
If you put this in the application, you could do something such as:
my @manufacturers = fetch(select manufacturer_no, name from
manufacturers);
my @select_fields = ('product_no');
foreach my $manufacturer (@manufacturers) {
my $manuf_no = $manufacturer-{manufacturer_no};
my $name =
On Tue, 2008-08-19 at 07:34 -0400, Bill Moran wrote:
In theory, you can have so many disks that the bottleneck moves to
some
other location, such as the IO bus or memory or the CPU, but I've
never
heard of that happening to anyone. Also, you want to get fast, high-
quality disks, as 10
On Sat, 2008-08-16 at 11:42 +0800, Amber wrote:
Dear all:
We are currently considering using PostgreSQL to host a read only
warehouse, we would like to get some experiences, best practices and
performance metrics from the user community, following is the question list:
1. What's size
On Mon, 2008-07-14 at 19:44 -0500, Bayless Kirtley wrote:
An old app is giving a new error message. I query a table and make one
update. Later I come back to query the table again and get this error:
ERROR: current transaction is aborted, commands ignored until end of
transaction block
On Mon, 2008-06-23 at 11:21 -0700, Steve Atkins wrote:
http://www.postgresql.org/about/ has some of the theoretical limits.
In real use you're unlikely to hit any limits, theoretical or
practical, but if you start to use a silly number of tables and so
on
you're likely to hit
update foo
set foo_id = g.goo_id
from goo g
where foo.foo_id = g.goo_id and foo.foo_id is not null
I think. :)
-Mark
On Mon, 2008-06-23 at 21:43 +0200, Daniel Futerman wrote:
Hi,
Looking for the correct syntax for an UPDATE LEFT JOIN query in
PostgreSQL.
The equivalent MySQL query is :
16 matches
Mail list logo
