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
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
spammed. ;-)
>
And that sums up why I wish to thank everyone for the responses.. :)
*Robins*
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*
... WHERE didn't bring up any rows,
you would need to do an INSERT anyway.
Read more about SELECT ... FOR UPDATE here:
http://www.postgresql.org/docs/8.3/static/sql-select.html#SQL-FOR-UPDATE-SHARE
*Robins*
On Thu, Apr 3, 2008 at 2:48 PM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
> &
Coming to think of it.
Would it fine to consider that an UPDATE query that found no records to
update is (performance wise) the same as a SELECT query with the same WHERE
clause ?
As in, does an UPDATE query perform additional overhead even before it finds
the record to work on ?
*Robins*
On
(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
*
TE NO ACTION ON DELETE NO ACTION,
CONSTRAINT xz1 FOREIGN KEY (xz1)
REFERENCES z (z1) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION
)
INSERT INTO x (x1, xy1, xz1, xy2, xz2)
SELECT 1, y1, z1, y2, z2
FROM y, z
WHERE y1 = 1
AND z1 = 1;
*Robins*
On Jan 14, 2008 11:49 PM, P
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 u
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/29/07, Robins Tharakan <[EMAIL PROTECTED]> wrote:
>
> Thanks Tom,
Oops!
Guess I shot myself in the foot there.
It seems to be an SQL issue and not really a PG problem... Sorry for
bothering you all.
However, now that we are here, could anyone tell if you would advise for
multiple schemas (in PG) while designing the database structure ?
Thanks
Robins Tharakan
t_schemecode.scheme_code),
(SELECT stated_index FROM fundsys1.main where main.scheme_code =
jn_set_schemecode.scheme_code),
processing.number_of_companies_in_index(jn_set_schemecode.scheme_code,
lookup_tables.month.month_end_date),
processing.percentage_of_assets_in_stocks_as_in_benchmark(jn_set_schemecode.scheme_code,
lookup_tables.month.month_end_date)
FROM lookup_tables.month, fundsys1.main
INNER JOIN output.jn_set_schemecode ON
jn_set_schemecode.scheme_code = main.scheme_code
WHERE jn_set_schemecode.set_id=10
AND main.variant_scheme_code = main.scheme_code
ORDER BY main.scheme_code
==
Thanks
Robins Tharakan
ndidate' for a sequential scan as compared to B in this scenario ?
Or is it the other way around ?
Regards,
Robins Tharakan
On 5/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Paul Smith <[EMAIL PROTECTED]> writes:
> If I do
> EXPLAIN SELECT * FROM x ORDER BY a;
> it says
must have gone off air after tom's last email, and one can understand that).
But an analysis, or atleast a pointer may be of help to someone (like me)
reading this list.
Thanks
Robins
-- Forwarded message --
From: Tom Lane <[EMAIL PROTECTED]>
Date: Apr 13, 2007 10:08
must have gone off air after tom's last email, and one can understand that).
But an analysis, or atleast a pointer may be of help to someone (like me)
reading this list.
Thanks
Robins
-- Forwarded message --
From: Tom Lane <[EMAIL PROTECTED]>
Date: Apr 13, 2007 10:08
Hi,The documentation says that function blocks with exceptions are far costlier than without one.So if I need to implement an INSTEAD OF trigger (after checking for unique constraint violations) which way should I go ?
1. Get a table lock2. Use 'Select ... For Update' (which could be used to lock o
23 matches
Mail list logo
