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 fill
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 expens
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 (vertica
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 f
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
> pla
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?"
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 i
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
index2(
Gregory, thanks for all the insight! It is much appreciated.
Julian.
signature.asc
Description: This is a digitally signed message part.
On Dec 5, 2007 1:13 PM, Robert Bernabe <[EMAIL PROTECTED]> wrote:
> Anyways I'd like to break up this request/begging for help into two parts.
>
> 1) First would be settings of postgresql.conf. Did I do it correctly? The
> sample data is so smallI based my settings on the recommendations
> res
"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 joi
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 sa
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 with
processed data that is post-processed by a secondary sys
13 matches
Mail list logo
