Hello
2011/1/19 Ozz Nixon :
> A while back someone answered a question I was running into - poor
> performance on count(*) from a table which is constantly growing. The answer
> was like looking at oracle's V$ table - and I could get a semi-current count.
> (I do not need the exact count - just
raf wrote:
> Peter Eisentraut wrote:
>
> > On tis, 2011-01-18 at 10:33 +1100, raf wrote:
> > > p.s. if anyone in debian locale land is listening,
> > > 'E' does not sort before ','. what were you thinking? :-)
> >
> > What is actually happening is that the punctuation is sorted in a second
> > p
A while back someone answered a question I was running into - poor performance
on count(*) from a table which is constantly growing. The answer was like
looking at oracle's V$ table - and I could get a semi-current count. (I do not
need the exact count - just checking to make sure the table is g
Peter Eisentraut wrote:
> On tis, 2011-01-18 at 10:33 +1100, raf wrote:
> > p.s. if anyone in debian locale land is listening,
> > 'E' does not sort before ','. what were you thinking? :-)
>
> What is actually happening is that the punctuation is sorted in a second
> pass after the letters. Whic
On 18 Jan 2011, at 23:03, Raymond O'Donnell wrote:
>>> I suppose you meant particular? Yes, definitely. Although I'm sure
>>> some would find it peculiar as well :)
>>
>> Actually, "peculiar to" is perfectly correct here, though a bit
>> old-fashioned. According to my dictionary, it originally m
On 18/01/2011 19:34, Tom Lane wrote:
Alban Hertroys writes:
On 18 Jan 2011, at 19:59, James B. Byrne wrote:
I can see the motivation for something like DISTINCT ON. I take
it that this syntax is peculiar to PostgreSQL?:
I suppose you meant particular? Yes, definitely. Although I'm sure
som
On Tue, January 18, 2011 14:28, Alban Hertroys wrote:
>
> Nope, but some Googling put me on the right track. It's called a
> correlated subquery.
Thank you for this. I will delve further.
>> I can see the motivation for something like DISTINCT ON. I take
>> it that this syntax is peculiar to
On Jan 18, 2011, at 14:52, A.M. wrote:
> Is there a better way?
Use dollar quotes or standard quoting instead of E strings.
Michael Glaesemann
grzm seespotcode net
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgr
Hello,
The following statement replaces an asterisk in a string with a double-escaped
asterisk:
SELECT regexp_replace('*',E'\\*',E'\*');
I got this result through experimentation and I am at a loss to explain why so
much escaping is necessary for the third argument. Is there a better wa
On Sat, 2011-01-15 at 21:32 +0100, Tomas Vondra wrote:
> > ALTER TABLE event ADD CONSTRAINT event_overlap
> > CHECK(overlap_at_dest(destination_id, starts, ends));
>
> There's a race condition
...
> One way to fix this is locking
I do not recommend locking. In fact, the prima
Alban Hertroys writes:
> On 18 Jan 2011, at 19:59, James B. Byrne wrote:
>> I can see the motivation for something like DISTINCT ON. I take it
>> that this syntax is peculiar to PostgreSQL?:
> I suppose you meant particular? Yes, definitely. Although I'm sure some would
> find it peculiar as we
On Sat, 2011-01-15 at 15:07 -0500, Daniel Popowich wrote:
> Constraint expressions can only be simple boolean expressions, so can
> refer only to the column(s) of the current row you're
> inserting/updating,
Exclusion Constraints are a new feature in 9.0:
http://www.postgresql.org/docs/9.0/stati
On 18 Jan 2011, at 19:59, James B. Byrne wrote:
>
> On Tue, January 18, 2011 13:23, Alban Hertroys wrote:
>>
>>
>> Standard SQL alternatives tend to get complex, using self-joins to
>> weed out all the records you don't want (the exact term for such
>> joins escapes me right now, that would hel
On Sat, 2011-01-15 at 19:17 +, Matthew Wilson wrote:
> create table event(
>
> destination_id integer not null references destination
> (destination_id),
>
> starts timestamp,
> ends timestamp
> );
>
> I want to make sure that no two rows **with the same destination_id**
> ov
On Tue, January 18, 2011 13:23, Alban Hertroys wrote:
>
>
> Standard SQL alternatives tend to get complex, using self-joins to
> weed out all the records you don't want (the exact term for such
> joins escapes me right now, that would help with Googling if you're
> looking for examples).
Would th
Hey folks,
PgEast is being held in NYC this year from 03/22-03-25. Get your papers
in, the deadline is soon!
http://www.postgresqlconference.org/
Joshua D. Drake
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support,
From: Peter Geoghegan
Subject: Re: [GENERAL] Case Insensitive Foreign Key Constraint
I would probably just have a check constraint that prevented the
relevant PK field from being lower case in the first place. I had to
do that recently, but my approach reflected the business rules.
This is wh
On 18 Jan 2011, at 19:02, James B. Byrne wrote:
> Given a table "shipments" having a column called "mode" I want to
> extract one entire shipment row (all columns) for each distinct
> value of mode. Assuming that there are 1700 rows and that there are
> just five distinct values in use for mode t
I am working with Ruby on Rails and I have stumbled into a situation
which turned out to be, surprisingly for me, somewhat involved.
Given a table "shipments" having a column called "mode" I want to
extract one entire shipment row (all columns) for each distinct
value of mode. Assuming that ther
I would probably just have a check constraint that prevented the
relevant PK field from being lower case in the first place. I had to
do that recently, but my approach reflected the business rules.
You may prefer to use citext:
http://www.postgresql.org/docs/current/interactive/citext.html
--
R
Hi all,
Is there a way to have text-type foreign keys be case insensitive?
development=# CREATE TABLE foo (foo text PRIMARY KEY);
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for
table "foo"
CREATE TABLE
development=# INSERT INTO foo VALUES ('foo');
INSERT 0 1
dev
My PITR work well from 01/01/2011 to 06/01/2011. At 06/01/2011 postgresql
log have issue
2011-01-06 08:27:48 ICT LOG: autovacuum: found orphan temp table
"pg_temp_19"."cdvt13newtmp" in database "cpnvn_data"
2011-01-06 08:27:48 ICT LOG: autovacuum: found orphan temp table
"pg_temp_49"."tmpct70s" i
I found the bug and it has been reported. Bug #5842.
Details here:
http://archives.postgresql.org/pgsql-bugs/2011-01/msg00134.php
Dan Popowich
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
=?KOI8-R?B?99HexdPMwdcg4szJzs7Jy8/X?= writes:
> Yeah - that is how I do (PGgetResult function returns results until it will
> return "NULL" pointer which means that all data for whole "PGsendQuery" was
> returned). But what does it mean when query which contain 3 "SELECT"
> commands returns just o
Yeah - that is how I do (PGgetResult function returns results until it will
return "NULL" pointer which means that all data for whole "PGsendQuery" was
returned). But what does it mean when query which contain 3 "SELECT"
commands returns just one result (second "PGgetResult()" already returns
null
On Sun, Jan 16, 2011 at 12:28 PM, Andy Colson wrote:
On 01/16/2011 10:44 AM, Mag Gam wrote:
I am running Redhat 5.2 Linux with Postgresql 8.4.4;
When my disk space is 90% free the database performance is very good.
However, when it reaches close to 20% free the database performance is
bad. I
Hi,
I have tried initdb manually, it failed:
initdb -D "D:\\Amber\\Program\\PostgreSQL\\9.0\\data"
--lc-messages=English -U postgres E UTF8 -A md5
and unfortunately initdb can't show the error messages probably, I
think it is because of encoding, my notebook is in Simplified Chinese
Locale, and I
Alex Hunsaker writes:
> FYI if I don't use a slice copy here I can't get it to leak. ( find my
> test case at the end ) I don't know enough about python to know if
> thats a pl/python issue or python doing what its told-- having never
> really wrote any python myself.
>
> ---
> -- le
Hi,
I know you people have talked a lot about this, but until now I
still can't install the newest release installed on my new Win7 Home
basic 64 bit notebook, the user I run has administration previliege,
and I have tried C and POSIX locale, neither works. The error message
are the same:
Probl
On 18/01/2011 13:43, Mag Gam wrote:
Purge meaning, stop postgresql, rm -rf $PGDATA, recreate the
environment, and start up postgresql again.
Goodness, that's fairly dramatic. What's wrong with DROP DATABASE? :-)
Ray.
--
Raymond O'Donnell :: Galway :: Ireland
r...@iol.ie
--
Sent via pgsql-gen
Purge meaning, stop postgresql, rm -rf $PGDATA, recreate the
environment, and start up postgresql again.
On Tue, Jan 18, 2011 at 8:32 AM, Bill Moran wrote:
> In response to Mag Gam :
>
>> Hi Andy,
>>
>> No, I don't shrink the database. I simply purge the whole thing and
>> then let it populate
In response to Mag Gam :
> Hi Andy,
>
> No, I don't shrink the database. I simply purge the whole thing and
> then let it populate again. The data isn't too critical.
What does "purge" mean? Are you doing an SQL DELETE, or a TRUNCATE,
or dropping the DB and recreating?
Each of these functions
Hi Andy,
No, I don't shrink the database. I simply purge the whole thing and
then let it populate again. The data isn't too critical.
The disks I have are internal SAS disks. I get around 150MB/sec write
and 250MB/sec read. Its a RAID1 .
ps does show idle in transactions. I've never checked pg_l
Hey,
18 января 2011 г. 14:24 пользователь Вячеслав Блинников
написал:
> By which rules database returns results for multiple commands within single
> query?
> For example I send (execute) such query (obtain different information about
> just connected client):
> "SELECT column1 FROM table1; SELEC
By which rules database returns results for multiple commands within single
query?
For example I send (execute) such query (obtain different information about
just connected client):
"SELECT column1 FROM table1; SELECT column2 FROM table2; SELECT column3 FROM
table3;"
And when I get response I expe
Hi all..
Start from vacuum feature information from PGSQL helps documentation, it
telling me that Postgresql didn't delete data permanently when we execute
delete command, it just made the data invalid. By following this email
archive :
http://archives.postgresql.org/pgsql-admin/2005-01/msg001
36 matches
Mail list logo
