the corresponding values genuinely don't exist
in the other table, so that's ok.
--
Robins Tharakan
smime.p7s
Description: S/MIME Cryptographic Signature
estimates on Machine B seem odd, coz they shoot up from 10k to the order
of billions without any big change in row-count. Beats me.
--
Robins Tharakan
1. For Machine A, what can I do to make the planner choose the faster
plan without setting enable_nestloop=false ?
2. From the research I have done
on large_table_a
(cost=0.00..1.23 rows=1 width=4) (actual time=0.004..0.004 rows=0
loops=6938)
Index Cond: (large_table_a.field_a = s1.field_a)
Total runtime: 98.165 ms
--
Robins Tharakan
On 10/18/2011 06:16 PM, Kevin Grittner wrote:
We build from source, and we include the minor
Hi Radhya,
Make multiple EXPLAIN requests, and add them up in your application, I
guess?
--
Robins
Sr. PGDBA
Comodo India
On 10/22/2011 06:41 AM, Radhya sahal wrote:
such as
explain (q1,q2,q3)..i want the total cost for all queries in the
workload using one explain ,,??
smime.p7s
.field_a = s2.field_a
WHERE s2.field_b = 2673056
--
Robins Tharakan
smime.p7s
Description: S/MIME Cryptographic Signature
.field_b = s2.field_b)
- Index Scan using PK_large_table_a on large_table_a
(cost=0.00..1.23 rows=1 width=4) (actual time=0.011..0.011 rows=0 loops=16)
Index Cond: (large_table_a.field_a = s1.field_a)
Total runtime: 0.620 ms
--
Robins Tharakan
smime.p7s
Description: S/MIME
On Wed, May 21, 2008 at 1:27 PM, J. Andrew Rogers [EMAIL PROTECTED]
wrote:
On May 21, 2008, at 12:33 AM, Shane Ambler wrote:
Size can affect performance as much as anything else.
For a brief moment, I thought the mailing list had been spammed. ;-)
And that sums up why I wish to thank
on the performance, I would certainly want to take that
into account during design phase.
Any pointers / replies appreciated.
Regards,
*Robins Tharakan*
I think James was talking about Sybase. Postgresql on the other hand has a
slightly better way to do this.
SELECT ... FOR UPDATE allows you to lock a given row (based on the SELECT
... WHERE clause) and update it... without worrying about a concurrent
modification. Of course, if the SELECT ...
*
On Tue, Apr 1, 2008 at 7:53 AM, Robins Tharakan [EMAIL PROTECTED] wrote:
I get into these situations quite often and use exactly what stephen
pointed out.
Do an Update, but if not found, do an insert. Its (by and large) better
than your version 2 since here you may skip running the second query
) accurate count ?
SELECT COUNT(*) from table WHERE indexed_field IS NULL
+
SELECT COUNT(*) from table WHERE indexed_field IS NOT NULL
*Robins Tharakan*
-- Forwarded message --
From: Greg Smith [EMAIL PROTECTED]
Date: Tue, Mar 11, 2008 at 4:31 AM
Subject: Re: [PERFORM] count
Frankly put, i didn't know that this perspective exists and then thanks for
putting it that way then !!
Guess I should take a relook at how I plan to use those VIEWS.
Thanks
*Robins*
A rule of thumb is that ORDER BY in a view is bad design, IMHO.
regards, tom lane
would be really helpful.
Regards,
*Robins Tharakan*
Hi Patric,
This doesn't seem to be a question pertaining to the PERFORM queue.
If I understand you correctly, this should solve your problems, without the
need for any RULES / TRIGGERS.
CREATE TABLE y
(
y1 int4 NOT NULL,
y2 varchar,
CONSTRAINT a PRIMARY KEY (y1)
)
CREATE TABLE z
(
z1
Thanks Tom,
Exactly what I did, when I realised that there was an extra Table in the
FROM with no conditions set.
Well anyway, this did clear my doubts about whether schema affects
performance at all.
Robins
On 8/28/07, Tom Lane [EMAIL PROTECTED] wrote:
Schemas are utterly, utterly
Hi Tom / Steve,
Am one of the silent readers of performance issues that come up on this list
(and are discussed in detail) ... just like this one.
If and when you do come up with a solution, please do post some details
about them here... (i say that coz it seems that for obvious reasons, things
16 matches
Mail list logo
