> On 21 Feb 2015, at 12:03, Arup Rakshit wrote:
>
> On Saturday, February 21, 2015 12:42:03 PM Alban Hertroys wrote:
>>
>>> On 21 Feb 2015, at 9:34, Arup Rakshit wrote:
>>>
>>> Select * from Emp
>>> where (attr1 = val11 and attr2 = val12 and attr3 = val13) or (attr1 =
>>> val14and attr2 = v
On Saturday, February 21, 2015 12:42:03 PM Alban Hertroys wrote:
>
> > On 21 Feb 2015, at 9:34, Arup Rakshit wrote:
> >
> > Select * from Emp
> > where (attr1 = val11 and attr2 = val12 and attr3 = val13) or (attr1 =
> > val14and attr2 = val15 and attr3 = val16);
> >
> > Now suppose I got (x1,
> On 21 Feb 2015, at 9:34, Arup Rakshit wrote:
>
> Select * from Emp
> where (attr1 = val11 and attr2 = val12 and attr3 = val13) or (attr1 =
> val14and attr2 = val15 and attr3 = val16);
>
> Now suppose I got (x1, x2, x3) and (y1, y2, y3). Then I need to rewrite my
> query as :
>
> Select *
On Wed, Oct 29, 2014 at 8:47 PM, David Johnston
wrote:
> On Wed, Oct 29, 2014 at 12:14 PM, Jorge Arevalo > wrote:
>
>>
>> SELECT value1,value2,value3,value4, value5, hstore(ARRAY['field9',
>> 'field10', 'field11', 'field12', 'field13', 'field14'], ARRAY[field9,
>> field10, field11, field12, fiel
On Wed, Oct 29, 2014 at 12:14 PM, Jorge Arevalo
wrote:
>
> SELECT value1,value2,value3,value4, value5, hstore(ARRAY['field9',
> 'field10', 'field11', 'field12', 'field13', 'field14'], ARRAY[field9,
> field10, field11, field12, field13, field14]) as metadata, value7, (select
> array((select row(f1
Jorge Arevalo writes:
>> On Wed, Oct 29, 2014 at 11:53 AM, Tom Lane wrote:
>>> I'm also a bit confused as to why the planner is saying that the (SELECT
>>> ARRAY(...)) bit is an InitPlan and not a SubPlan. That implies that
>>> "field7" in the innermost WHERE clause is not a reference to table1
On Wed, Oct 29, 2014 at 8:05 PM, David Johnston
wrote:
> On Wed, Oct 29, 2014 at 11:53 AM, Tom Lane wrote:
>
>> Jorge Arevalo writes:
>>
>> > This is the result of EXPLAIN ANALYZE
>>
>> >QUERY
>> > PLAN
>> >
>>
On Wed, Oct 29, 2014 at 11:53 AM, Tom Lane wrote:
> Jorge Arevalo writes:
>
> > This is the result of EXPLAIN ANALYZE
>
> >QUERY
> > PLAN
> >
>
Jorge Arevalo writes:
> SELECT value1,value2,value3,value4,
> value5, hstore(ARRAY['field9', 'field10', 'field11', 'field12', 'field13',
> 'field14'], ARRAY[field9, field10, field11, field12, field13, field14) as
> metadata, value7, (select array((select row(f1, f2) from table2 p where
> p.f3 = fi
List preference is to inline post or, at worse, bottom post. Please do not
top post.
On Wed, Oct 29, 2014 at 11:06 AM, Jorge Arevalo
wrote:
> Hello David, many thanks for your responses,
>
> Sorry for not providing the content of the fill_table3_function, but it
> just executes 3 insert queries
Hello David, many thanks for your responses,
Sorry for not providing the content of the fill_table3_function, but it
just executes 3 insert queries in 3 different tables. And I've checked the
time consuming operation is in this query (by the way, there was a little
mistake in the name of the field
Jorge Arévalo-2 wrote
> (SELECT value1,value2,value3,value4,value5, hstore(ARRAY['field9',
> 'field10', 'field11', 'field12', 'field13', 'field14'], ARRAY[field9,
> field10, field11, field12, field13, field14) as metadata, value7, (select
> array((select row(f1, f2) from table2 p where p.field7 = f
Jorge Arévalo-2 wrote
> So, I first generate a common table records_to_insert, using data from
> table1 and table2, and then call a function fill_table3_function, in order
> to insert the values into table3 (I do more things apart from insert,
> that's reason to call a function instead of just rais
Hi,
On Wed, Apr 11, 2012 at 2:28 PM, wrote:
> I'm looking for materials about query optimization in PostgreSQL. I read
> documentation but it doesnt contain much information. Can you recommend a
> good book or website when i could learn something about this?
I think you can find some good in
ot;Index Cond: ($0 = securitytypekey)"
So this proves it is using the index.
But I think the issue is in the interaction between the numbers of rows
returned from positions_gsco and security.
kd
-Original Message-
From: Klint Gore [mailto:[EMAIL PROTECTED]
Sent: Thurs
Kevin Duffy wrote:
So here are the questions for the PSQL gurus:
Is getsectypekey(‘CFD’) executing for every join (or possible join)
between positions_gsco and security?
Causing a scan of security for every possible join.
Does ‘ (select getsectypekey('CFD') ) ‘ cause the getsectype()
funct
What does the output of explain select sec.* ... have to say?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Orest Kozyar wrote:
What I am wondering is whether the database first eliminate all rows in
tableA that don't meet the criteria before performing the join, or does it
perform the join first then eliminate all records that don't meet the
criteria?
If you use "EXPLAIN SELECT ..." then PostgreSQL
> --- Original Message ---
> From: Peter <[EMAIL PROTECTED]>
> To: pgsql-general@postgresql.org
> Sent: 03/02/07, 10:58:08
> Subject: Re: [GENERAL] Query optimization problem
>
> >>> Try SELECT count(*) FROM ... instead and see if the times are clos
Try SELECT count(*) FROM ... instead and see if the times are closer.
Correct. That executes in 300ms flat:
So your problem is data transfer, not the query per se.
Well, based on PgAdmin times I suspected some sort of heavy 'data
preparation before it's sent out' overhead
How old a pgAdm
Peter <[EMAIL PROTECTED]> writes:
>> Try SELECT count(*) FROM ... instead and see if the times are closer.
> Correct. That executes in 300ms flat:
So your problem is data transfer, not the query per se.
How old a pgAdmin are you using?
regards, tom lane
>> I'm not sure if I'm heading up the right alley - seems too simple!,
but here is my issue.
>>
>> I have about 3000 records in 'mytable', and simple
>
>Number of rows is not the most important thing here - the number of
>occupied disc pages is (you can have a lot of small rows or a small
>nub
Query returned successfully with no result in 600 ms.
Why SELECT takes 3+ second to execute? Is it something to do with my
Postgres server optimization, or PgAdmin does not show correct data
retrieval runtime (leaks over into query runtime or something)?
Data transfer and display time usually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/02/07 07:22, Richard Huxton wrote:
> Peter wrote:
>>
>> Query returned successfully with no result in 600 ms.
>>
>> Why SELECT takes 3+ second to execute? Is it something to do with my
>> Postgres server optimization, or PgAdmin does not show cor
Richard Huxton wrote:
Peter wrote:
Query returned successfully with no result in 600 ms.
Why SELECT takes 3+ second to execute? Is it something to do with my
Postgres server optimization, or PgAdmin does not show correct data
retrieval runtime (leaks over into query runtime or something)?
Peter wrote:
Query returned successfully with no result in 600 ms.
Why SELECT takes 3+ second to execute? Is it something to do with my
Postgres server optimization, or PgAdmin does not show correct data
retrieval runtime (leaks over into query runtime or something)?
Data transfer and displ
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> only the a = 5 clause would be used with the index. As of 8.1 it will
>> consider using nonconsecutive index columns
> Really? Is this the "skip scan" plan people were pining for?
No, there's no skip scan, it jus
Tom Lane <[EMAIL PROTECTED]> writes:
> Before (if memory serves) 8.1, the planner would only consider leading
> index columns as potential indexscan qualifiers. So given
>
> where a = 5 and c = 4;
>
> only the a = 5 clause would be used with the index. As of 8.1 it will
> consider using
[EMAIL PROTECTED] writes:
> Suppose I have an index on 5 columns (A, B, C, D, E).
> If my WHERE clause is not in that order, will the optimizer reorder
> them as necessary and possible?
Yes, the optimizer understands about commutativity/associativity of
AND and OR ;-)
> If I don't specify co
On Fri, Sep 30, 2005 at 06:24:52PM -0400, Sean Davis wrote:
>-> Seq Scan on u_all_est_mrna c (cost=0.00..932582.74 rows=24225174
> width=179) (actual time=17.384..302484.904 rows=24225174 loops=1)
That step is where most of your time is being spent, which isn't
surprising given that it's sca
hi guys , Richad
you are right!, my apologies
profile data:
postgres: "PostgreSQL 7.4.3 on i386-pc-linux-gnu,
compiled by GCC 2.95.4"
HP proliant
processor: Dual Xeon 3.40 Ghz.
HD:250 Gigabytes hard disk storage.
responses:
> Comment 4 - you apply a LIMIT without an ORDER BY.
> Are
marcelo Cortez wrote:
hi guys
i need advice for query optimization,take too long
time.
any coments are welcomed :).
Comment 1 - you'll need to post the output of "EXPLAIN ANALYSE", not
just EXPLAIN, otherwise people can't see how long it took.
Comment 2 - you provide the definition of o
Jeff Davis <[EMAIL PROTECTED]> writes:
> I had an idea about using aggregates: what if I made an aggregate function
> called "first" that just returned the value in the first tuple it
> encountered?
You could make that work in 7.4, but not in any existing releases.
The trouble is that you need
33 matches
Mail list logo
