2013/7/5 Greg Jaskiewicz
> Hey,
>
> We have a search method that depending on search params will join 3-5
> tables, craft the joins and where section. Only problem is, this is done in
> rather horrible java code. So using pgtap for tests is not feasible.
> I want to move the database complexity b
On Friday, May 10, 2013, Robert Haas wrote:
> On Sat, Mar 23, 2013 at 8:12 PM, Misa Simic
> >
> wrote:
> > but problem is - we don't know the thing id - we know calc_id:
> >
> > EXPLAIN ANALYZE
> > SELECT * FROM t2_left_t3_volatile v INNER JOIN t1 USING (
Hi,
We again have problems with query planer... (Ubuntu, pg 9.1)
Up to now - solution was "rephrase the question", but for next thing we are
not sure what would be best solution...
the whole story is too complex... but simplified:
We have tables:
things (thing_id int pk... other columns...)
ac
HI,
I have a wierd problem with PostgreSQL planner...
Problem showed up in Production on PG9.1 (Ubuntu)
But I have succeeded to get the same behavior on my PG 9.2 on Windows...
it is about 3 tables & onad one view - but view have volatile function:
CREATE TABLE t1
(
calc_id serial NOT NULL,
Hi Jeff,
It seems my previous mail has not showed up in the list... copied/pasted
again belloew
However, you said something important:
"The join to the "state" table is not necessary. Between the foreign key
and the primary key, you know that every state exists, and that every state
exists only
Hi,
there is something mixed..
your index is on table1
Explain Analyze reports about table called: busbase
Kind Regards,
Misa
2013/3/22 Cindy Makarowsky
> But, I do have an index on Table1 on the state field which is in my group
> by condition:
>
> CREATE INDEX statidx2
> ON ta
:(
Ah - 9.1.0 is postgres version on Ubuntu...
Thanks Jeff - you saved me some time - reorganising functions to work with
different tables would take time... what potentially will not give us
solution :(
Many thanks,
Misa
2013/3/12 Jeff Janes
> On Tue, Mar 12, 2013 at 7:13 AM, Misa Si
Misa
2013/3/12 Steve Crawford
> On 03/12/2013 08:06 AM, Misa Simic wrote:
>
>> Thanks Steve
>>
>> Well, the full story is too complex - but point was - whatever blackbox
>> does - it last 0.5 to 2secs per 1 processed record (maybe I was wrong but I
>> thought
it goes with insert into unlogged tables with no FK...
Many thanks,
Misa
2013/3/12 Steve Crawford
> On 03/11/2013 08:55 PM, Misa Simic wrote:
>
>> Hi all,
>>
>> We have one table with list of "records for processing"...
>>
>> We loop trough that
?
Thanks,
Misa
2013/3/12 Misa Simic
> Hi all,
>
> We have one table with list of "records for processing"...
>
> We loop trough that table and call one long runing function:
>
> do_the_math_for_record(record_id)
>
> which use different tables for sel
Hi all,
We have one table with list of "records for processing"...
We loop trough that table and call one long runing function:
do_the_math_for_record(record_id)
which use different tables for select related rows for input record_id, do
some calculations and insert results in two tables...
an
her page) if calculation is
done, return results from cache (with real total number)... But it is
really on very exceptional basis then on regular...
Cheers
Misa
Sent from my Windows Phone
From: Andrew Dunstan
Sent: 09/07/2012 19:47
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] P
2012/7/9 Gregg Jaskiewicz
> Use cursors.
> By far the most flexible. offset/limit have their down sides.
>
Well, I am not aware what down sides there are in LIMIT OFFSET what does
not exist in any other solutions for paged queries... But agree there
always must be some compromise between flexib
Hi Hermann,
Well,
Not clear how you get rows for user without paging?
If it is some query:
SELECT columns FROM table WHERE UserHasPerimision(rowPK, userid)
Paging would be:
SELECT columns FROM table WHERE UserHasPerimision(rowPK, userid) LIMIT
NoOfRecords OFFSET page*NoOfRecords
Kind Regards
... But I
think it is more personal feelings which is better then real...
Sent from my Windows Phone
From: Jochen Erwied
Sent: 07/01/2012 15:18
To: Misa Simic
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Duplicate deletion optimizations
Saturday, January 7, 2012, 3:02:10 PM you wrote
If solution with temp table is acceptable - i think steps could be
reduced...
• copy to temp_imp ( temp table does not have id column)
• update live set count = temp_imp.count from temp_imp using (
col1,col2,col3)
• insert into live from temp where col1, col2 and col3 not exists in
live
Kind Re
hi,
Maybe these thoughts could help
1) order by those three columns in your select min query could force
index usage...
2) or
DELETE FROM table
WHERE EXISTS(SELECT id FROM table t WHERE t.id > table.id AND t.col1 =
table.col1 AND t.col2 = table.col2 AND col3 = table.col3)
Sent from my Wi
17 matches
Mail list logo
