A Dimarts 11 Març 2008 04:11, Scott Marlowe va escriure:
> On Mon, Mar 10, 2008 at 7:57 PM, Robins Tharakan <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I have been reading this conversation for a few days now and I just
> > wanted to ask this. From the release notes, one of the new additions in
> >
Simon Riggs wrote:
On Mon, 2008-03-10 at 11:01 +, Heikki Linnakangas wrote:
According
to oprofile, all the time is spent in TransactionIdIsInProgress.
I recently submitted a patch to optimise this. Your comments would be
welcome on the patch.
You mean this one:
http://archives.postgres
I have one table with 30 fields, i have more then 60 million records, if i
use more no of indexes will it affect the insertion
performance? and select performance?
Shall i have more then one partial index for same field,
--
With Best Regards,
Petchimuthulingam S
In response to "Robins Tharakan" <[EMAIL PROTECTED]>:
> Hi,
>
> I have been reading this conversation for a few days now and I just wanted
> to ask this. From the release notes, one of the new additions in 8.3 is
> (Allow col IS NULL to use an index (Teodor)).
>
> Sorry, if I am missing somethin
how to find trigger names in my database ?
using psql 7.4
the following query shows system triggers, i want only to list the
triggers created by me
select relname, tgname, tgtype, proname, prosrc, tgisconstraint,
tgconstrname, tgconstrrelid, tgdeferrable, tginitdeferred, tgnargs,
tgattr, tgargs
On 11-Mar-08, at 8:28 AM, petchimuthu lingam wrote:
I have one table with 30 fields, i have more then 60 million
records, if i use more no of indexes will it affect the insertion
performance? and select performance?
Yes, and yes, but without more information about what you are trying
to do
On Tue, 11 Mar 2008, Bill Moran wrote:
In response to "Robins Tharakan" <[EMAIL PROTECTED]>:
Sorry, if I am missing something here, but shouldn't something like this
allow us to get a (fast) accurate count ?
SELECT COUNT(*) from table WHERE indexed_field IS NULL
+
SELECT COUNT(*) from table WH
Hi,
Matthew wrote:
On Tue, 11 Mar 2008, Bill Moran wrote:
In response to "Robins Tharakan" <[EMAIL PROTECTED]>:
Sorry, if I am missing something here, but shouldn't something like this
allow us to get a (fast) accurate count ?
SELECT COUNT(*) from table WHERE indexed_field IS NULL
+
SELECT C
On Tue, 11 Mar 2008, Tino Wildenhain wrote:
And certain, qualified definitions of "accurate" as well. Race condition?
You mean in a three-state-logic? null, not null and something different?
True, False, and FILE_NOT_FOUND.
No, actually I was referring to a race condition. So, you find the c
Matthew wrote:
No, actually I was referring to a race condition. So, you find the count
of rows with IS NULL, then someone changes a row, then you find the
count of rows with IS NOT NULL. Add the two together, and there may be
rows that were counted twice, or not at all.
Not a problem if you
On Tue, Mar 11, 2008 at 02:19:09PM +, Matthew wrote:
> of rows with IS NULL, then someone changes a row, then you find the count
> of rows with IS NOT NULL. Add the two together, and there may be rows that
> were counted twice, or not at all.
Only if you count in READ COMMITTED.
A
--
Sen
Thank you for your post. I finally spent some quality time with the query
planner section in the docs' server config chapter. Very instructive, even
considering that most of it went over my head!
On Sat, Mar 8, 2008 at 4:08 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
...have you got effective_cache
petchimuthu lingam wrote:
> I have one table with 30 fields, i have more then 60 million records, if
> i use more no of indexes will it affect the insertion
> performance? and select performance?
Maintaining an index has a cost. That means that every time a record
covered by an index is added, del
thanks...
after this query also it is showing default triggers ( am very much worried
that how the system triggers are created using my username
ok i posted this in the group you specified..
On Tue, Mar 11, 2008 at 8:03 PM, Sergey Benner <[EMAIL PROTECTED]>
wrote:
> Again :) Try this query.
>
> select usename,relname, tgname, tgtype, proname, prosrc, tgisconstraint,
> > tgconstrname, tgconstrrelid, tgdeferrable, tginitdeferred, tgnargs,
> > tgattr, tgargs from (pg_trigger join pg_class c on tgrelid=c.oid )
> > join pg_proc on (tgfoid=pg_proc.oid) join pg_user pu on
> > c.relowner=pu.u
Is there any article describing the migration database from postgresql 7.4to
8.1
sathiya psql wrote:
Is there any article describing the migration database from postgresql 7.4to
8.1
This might be a silly question, but ... why 8.1 ?
If you're doing a major upgrade, why not go straight to 8.3? It's been
out long enough that there aren't any obvious nasty bugs, and there have
>
> This might be a silly question, but ... why 8.1 ?
>
> If you're doing a major upgrade, why not go straight to 8.3? It's been
> out long enough that there aren't any obvious nasty bugs, and there have
> been a fair few fixes and improvements since prior versions.
>
Because am using Debian ETCH s
>
> This might be a silly question, but ... why 8.1 ?
how it will be a silly question
I thought that some manual changes are required... so am asking this may
be argument for functions had changed.. or any other changes...
>
> --
> Craig Ringer
>
sathiya psql wrote:
This might be a silly question, but ... why 8.1 ?
If you're doing a major upgrade, why not go straight to 8.3? It's been
out long enough that there aren't any obvious nasty bugs, and there have
been a fair few fixes and improvements since prior versions.
Beca
sathiya psql wrote:
This might be a silly question, but ... why 8.1 ?
If you're doing a major upgrade, why not go straight to 8.3? It's been
out long enough that there aren't any obvious nasty bugs, and there have
been a fair few fixes and improvements since prior versions.
Because am using De
In the home page itself they were saying testing ... unstable
then we should not use that for live.
so i prefer 8.1 .
>
> You can get 8.3 from backports: http://www.backports.org/ - it's a
> debian project to get more up to date versions for existing stable
> releases (they
sathiya psql wrote:
This might be a silly question, but ... why 8.1 ?
how it will be a silly question
I thought that some manual changes are required... so am asking this may
be argument for functions had changed.. or any other changes...
There have been changes for sure... but I
My question is that how to migrate my database to 7.4 to 8.1
that is not only dumping the db and extracting that in 8.1 ..
If i do that whether it will work without problem, or i have to do some
manual changes is my question...
On Wed, 12 Mar 2008, sathiya psql wrote:
My question is that how to migrate my database to 7.4 to 8.1
that is not only dumping the db and extracting that in 8.1 ..
If i do that whether it will work without problem, or i have to do some
manual changes is my question...
you would need to look
sathiya psql wrote:
My question is that how to migrate my database to 7.4 to 8.1
that is not only dumping the db and extracting that in 8.1 ..
If i do that whether it will work without problem, or i have to do some
manual changes is my question...
Start by reading the postgresql 8.0 and 8.1
On Wed, 12 Mar 2008, Craig Ringer wrote:
sathiya psql wrote:
This might be a silly question, but ... why 8.1 ?
If you're doing a major upgrade, why not go straight to 8.3? It's been
out long enough that there aren't any obvious nasty bugs, and there have
been a fair few fixes and improvements
On Wed, 12 Mar 2008, sathiya psql wrote:
In the home page itself they were saying testing ... unstable
you are talking about the debian home page right?
then we should not use that for live.
so i prefer 8.1 .
Debian selected the version of Postgres for Etch about a ye
28 matches
Mail list logo
