On Dienstag 05 Mai 2009 Tom Lane wrote:
> Apparently this is just an index, not a constraint (the difference
> being that it was made with CREATE INDEX, not ALTER TABLE ADD
> CONSTRAINT). Try
Is there a performance difference? Or is it just a matter of taste which
one you use? Technically, are th
Carol Walter writes:
> I'm sorry, I should have included this. Here is what I'm seeing.
> This is PostgreSQL 8.3.6 on Solaris 10.
> km_tezt=# \d "tblPeople";
>Table "public.tblPeople"
>Column | Type |
>
On May 5, 2009, at 12:08 PM, Tom Lane wrote:
Carol Walter writes:
I don't know how they did this, but I have a table that has a
compound
field constraint. When I try to insert data into this table from an
app I'd developing the query fails because the data supposedly
violates the unique co
great, thanks a lot...
On Tuesday 05 May 2009 17:11:35 Tom Lane wrote:
> Marc Cousin writes:
> > On Tuesday 05 May 2009 16:35:11 Tom Lane wrote:
> >> Hmm ... is it likely that index entries with pathid = 120 are *very* few
> >> and far between in jobid order? It looks like we have no
> >> CHECK_
Carol Walter writes:
> I don't know how they did this, but I have a table that has a compound
> field constraint. When I try to insert data into this table from an
> app I'd developing the query fails because the data supposedly
> violates the unique constraint on these fields. The fields
Hello,
I don't know how they did this, but I have a table that has a compound
field constraint. When I try to insert data into this table from an
app I'd developing the query fails because the data supposedly
violates the unique constraint on these fields. The fields are first,
middle,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
"Maria L. Wilson" asked:
> Question - is there any maintenance type item that we could
> check for uncommitted transactions on a regular basis - outside
> of the pg_prepared_xacts table?
The latest version of check_postgres (a Postgres monitorin
Marc Cousin writes:
> On Tuesday 05 May 2009 16:35:11 Tom Lane wrote:
>> Hmm ... is it likely that index entries with pathid = 120 are *very* few
>> and far between in jobid order? It looks like we have no
>> CHECK_FOR_INTERRUPTS calls inside the loop in _bt_next(), which is
>> probably a mistake
On Tuesday 05 May 2009 16:35:11 Tom Lane wrote:
> Marc Cousin writes:
> > [ can't cancel this query ]
> >
> > Index Scan using file_jpfid_idx on file (cost=0.00..7327212.07
> > rows=2128 width=104)
> >Index Cond: (pathid = 120)
> >
> > "file_jpfid_idx" btree (jobid, pathid, filenameid)
>
Marc Cousin writes:
> [ can't cancel this query ]
> Index Scan using file_jpfid_idx on file (cost=0.00..7327212.07 rows=2128
> width=104)
>Index Cond: (pathid = 120)
> "file_jpfid_idx" btree (jobid, pathid, filenameid)
Hmm ... is it likely that index entries with pathid = 120 are *ve
Hi, I'm having a problem cancelling a query.
I've already had sometimes this kind of problem, but not this hard (and I
didn't find anything searching the archives, but still I remember seeing
discussions about this). Usually, it cancels in a few seconds to a minute.
I've run this query an hou
11 matches
Mail list logo
