This is a little strange - my response to this post apparently got lost
in the net?? I haven't received it back through the list nor it's
visible in the archieve. Yet, my exim logfile contains entry indicating
'delivery complited'???
But to the point.
All the EXPLAIN ANALISE I did on posggres v8.
Alban Hertroys <[EMAIL PROTECTED]> writes:
> There's practically no difference between SELECT 1 FROM ... and SELECT *
> FROM ...; the only added costs (AFAIK) are for actually fetching the
> column values and such. Pretty cheap operations.
You're both glossing over exactly the wrong thing, parti
On Mon, 2006-08-28 at 14:50 +0200, Alban Hertroys wrote:
> Rafal Pietrak wrote:
>
> > But when I look at ANALYSE output of comlog SELECT, I can see, that:
> > 1. the seq-scans is more expensive here: 170ms and 120ms respectively.
> > Any reasons for that?
> > 2. each scan has an additional job of:
Rafal Pietrak wrote:
Well. The logfiles don't have their own indexes but make foreign key
references over brand1/brand2/clty columns. Unique constreins are on the
target tables.
So there's no index on the logfiles then? (A foreign key constraint
doesn't create an index). It doesn't seem like i
On Mon, 2006-08-28 at 13:04 +0200, Alban Hertroys wrote:
> Rafal Pietrak wrote:
> > Total runtime: 822.901 ms
> > (7 rows)
> > -
>
> Just to make sure: You do have an appropriate index over the tables in
> that UNION?
Well. The logfiles don't have their ow
Rafal Pietrak wrote:
Thank you All for explanations. Looks loke that's what I was looking
for.
UNION ALL is quite satisfactory (830ms).
And yet, somwhere I loose c.a. 600ms (as compared to 120ms+80ms of each
respective 'raw' subquery) which as percentage seem signifficant.
Does anybody know
Thank you All for explanations. Looks loke that's what I was looking
for.
UNION ALL is quite satisfactory (830ms).
And yet, somwhere I loose c.a. 600ms (as compared to 120ms+80ms of each
respective 'raw' subquery) which as percentage seem signifficant.
Does anybody know where the processing g
On mán, 2006-08-28 at 10:23 +0200, Rafal Pietrak wrote:
> Hi all,
>
> Is there a way to speed up the query to my 'grand total' logfile,
> constructed as a UNION of smaller (specialised) logfiles?
>
I do not know if this is relevant to your case, but
possibly you can use a UNION ALL instead of a
Am Montag, 28. August 2006 10:23 schrieb Rafal Pietrak:
> Is there a way to speed up the query to my 'grand total' logfile,
> constructed as a UNION of smaller (specialised) logfiles?
If it is sufficient for your purpose, you will find UNION ALL to be
significantly faster.
--
Peter Eisentraut
h
Hi all,
Is there a way to speed up the query to my 'grand total' logfile,
constructed as a UNION of smaller (specialised) logfiles?
Access to log1/log2 is quick (If I'm reading ANALYSE log correctly, it's
c.a. 100ms each - and it feels like that, so presumebly I'm reading
ANALYSE just OK), but th
10 matches
Mail list logo
