at implies it will happen?
Its just luck. Sometimes the corresponding values genuinely don't exist
in the other table, so that's ok.
--
Robins Tharakan
smime.p7s
Description: S/MIME Cryptographic Signature
loops=2173)
Index Cond: (s1.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.004..0.004 rows=0
loops=6938)
Index Cond: (large_table_a.field_a = s1.field_a)
Total runtime: 98.16
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 it
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
Des
le_b_SampleId" on
large_table_b s1 (cost=0.00..9.99 rows=2 width=8) (actual
time=0.037..0.047 rows=3 loops=6)
Index Cond: (s1.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=
s2 ON s1.field_a = s2.field_a
WHERE s2.field_b = 2673056
--
Robins Tharakan
smime.p7s
Description: S/MIME Cryptographic Signature
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 wis
e a
considerable impact 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 ... WHE
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 sk
(fast) 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: [PER
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
>
backs would be really helpful.
Regards,
*Robins Tharakan*
ally, Case A is a far far simpler approach to understability (as
well as data storage) and if you ask my take ? I'll take Case A :)
*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 i
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 irre
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
17 matches
Mail list logo
