On Wednesday 23 July 2003 01:40, Reece Hart wrote:
> I'm trying to update a table but it's taking a very long time. I would
> appreciate any tips folks may have about ways to speed it up.
[snip]
> paprospect2 contains ~40M rows. The goal now is to migrate the data to
> the supertable-inherited colu
Hi ,
I have a view which is a union of select of certain feilds from
indentical tables. The problem is when we query a column on
which index exists exists foreach of the tables does not use the
indexes.
But when we query individual tables it uses indexes.
Regds
Mallah.
tradein_clients=# crea
On 23 Jul 2003 at 16:05, Jean-Christian Imbeault wrote:
> I have a database which is constantly being written to. A web server's
> log file (and extras) is being written to it. There are no deletions or
> updates (at least I think so :).
>
> As the web traffic increases so will the write intens
On Wednesday 23 July 2003 11:21, Rajesh Kumar Mallah wrote:
> Hi ,
>
> I have a view which is a union of select of certain feilds from
> indentical tables. The problem is when we query a column on
> which index exists exists foreach of the tables does not use the
> indexes.
>
>
> But when we query
I have these two tables with the same data on two different
machines (SuSE 8.2 and Gentoo both with 7.3.2):
schulz=> \d rechnung
Table "jschulz.rechnung"
Column | Type | Modifiers
+--+---
system | smallint | not null
jahr |
=?iso-8859-1?q?J=F6rg=20Schulz?= <[EMAIL PROTECTED]> writes:
> I'm not very familar with the output of the explain command but can you
> tell me why I get two different query plans?
Judging from the suspiciously round numbers in the cost estimates,
you've never done a VACUUM ANALYZE on any of thes
Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
> I have a view which is a union of select of certain feilds from
> indentical tables. The problem is when we query a column on
> which index exists exists foreach of the tables does not use the
> indexes.
Hard to be certain since you didn't show us
> Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
>> I have a view which is a union of select of certain feilds from
>> indentical tables. The problem is when we query a column on
>> which index exists exists foreach of the tables does not use the
>> indexes.
>
> Hard to be certain since you didn't
<[EMAIL PROTECTED]> writes:
> the column 'generated' was timestamp in 2 place and date in 2 place,
> i wanted it in my and did a typecasting in the view below
> but it suffers from the same problem .
AFAIR it should work if you insert casts into the UNION's member selects.
Maybe you didn't get the
Yep!
it works perfectly now.
CREATE or replace VIEW sent_enquiry_eyp_iid_ip_cat2 as ((SELECT
eyp_rfi.rfi_id, eyp_rfi.sender_uid, eyp_rfi.receiver_uid, eyp_rfi.subject,
cast(eyp_rfi.generated as timestamp with time zone ) FROM ONLY eyp_rfi)
UNION (SELECT iid_rfi.rfi_id, iid_rfi.sender_uid, i
Richard-
Thanks for the suggestions. I too had thought about the FK checks, even though the columns aren't getting updated.
I'm flabbergasted that the update is still running (~22 hours elapsed). By comparison, the database takes only 4 hours to recreate from backup! Something funny is happen
On Wed, 2003-07-23 at 10:47, Guthrie, Jeremy wrote:
Have you checked the sizes of your indexes? You may need to rebuild them...
Multiply the relpages colum by 8192.
So, what does this tell me? I'm guessing that you're implying that I should expect 8192 keys per page, and that this therefor
Look at it like this(this is how this affected me):
I had a table that use to be the primary home for my data(6 gigs worth). I copied out
and copied to another table. I purged and then I 'vacuum full''d the database. After
a day things really started going to hell. SLOOOW.. like 30 minutes to
> > I'm not very familar with the output of the explain command but can you
> > tell me why I get two different query plans?
>
> Judging from the suspiciously round numbers in the cost estimates,
> you've never done a VACUUM ANALYZE on any of these tables. Try that and
> then see what plans you ge
14 matches
Mail list logo