On Thursday 29 November 2007 11:14, Simon Riggs wrote:
On Thu, 2007-11-29 at 10:45 -0500, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
Tom's previous concerns were along the lines of How would know what
to set it to?, given that the
In response to Robert Bernabe [EMAIL PROTECTED]:
Hi All,
I've been tasked to evaluate PG as a possible replacement of our
MS SQL 2000 solution. Our solution is 100% stored procedure/function
centric.
I've trimmed 99% of your email out, because it's not relevant to my
answer.
Fact is,
On Dec 5, 2007 3:13 AM, Robert Bernabe [EMAIL PROTECTED] wrote:
Would it also make sense to optimize (as far as possible) everything
(including the code) for windows first? The target here would be a linux OS
but since the discrepancy is so big...the unified Windows OS might be a good
place to
I think you may increase the row number that you want to limit, like LIMIT
50.
LIMIT can change the cost of a plan dramatically. Looking in your SQL:
where this_.fkaddressid= 6664161
order by this_.addressvaluationid desc limit 1;
Planner may use either index1(this_.fkaddressid) or
On Dec 5, 2007 2:13 AM, Robert Bernabe [EMAIL PROTECTED] wrote:
Hi All,
I've been tasked to evaluate PG as a possible replacement of our MS SQL
2000 solution. Our solution is 100% stored procedure/function centric. It's
a report generation system whose sole task is to produce text files
Gregory, thanks for all the insight! It is much appreciated.
Julian.
signature.asc
Description: This is a digitally signed message part.
On Nov 19, 2007, at 9:23 AM, Tom Lane wrote:
Decibel! [EMAIL PROTECTED] writes:
FWIW, 20k rows isn't all that big, so I'm assuming that the
descriptions make the table very wide. Unless those descriptions are
what's being updated frequently, I suggest you put those in a
separate table (vertical
I don't know if this is true in this case, but transaction level can be
different, in mssql it is normally something like
TRANSACTION_READ_UNCOMMITTED
in postgres
TRANSACTION_READ_COMMITTED
and that makes huge difference in performance.
other thing can be the queries in procedures, if you use
Julian Mehnle [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Julian Mehnle [EMAIL PROTECTED] writes:
I actually do have constraints on all the partitions, e.g. for week
34: [...]
Shouldn't this be enough to give the query planner a clue that it
only has to join the email and
On Nov 28, 2007, at 7:27 AM, Bill Moran wrote:
Is there something wrong with:
set enable_seqscan = off
Note that in cases of very heavy skew, that won't work. It only adds
10M to the cost estimate for a seqscan, and it's definitely possible
to have an index scan that looks even more
On Wed, 2007-12-05 at 00:13 -0800, Robert Bernabe wrote:
Hi All,
I've been tasked to evaluate PG as a possible replacement of our
MS SQL 2000 solution. Our solution is 100% stored procedure/function
centric. It's a report generation system whose sole task is to produce
text files filled
11 matches
Mail list logo
