Simon Riggs <[EMAIL PROTECTED]> writes:
>> ISTM that when the BETWEEN constants match we end up in this part of
>> clauselist_selectivity()...
Yeah, I think you are right.
> so that the planner underestimates the cost of using "Cal_CalDate" so
> that it ends up the same as "Cal_CtofcNo", and then
On Wednesday 15 March 2006 18:21, Simon Riggs wrote:
> On Wed, 2006-03-15 at 14:39 -0500, Jan de Visser wrote:
> > After fixing the hanging problems I reported here earlier (by
> > uninstalling W2K3 SP1), I'm running into another weird one.
> >
> > After doing a +/- 8hr cycle of updates and inserts
On Thu, 2006-03-16 at 00:07 +, Simon Riggs wrote:
> On Wed, 2006-03-15 at 14:17 -0500, Tom Lane wrote:
>
> > It looks to me like this is a matter of bad cost estimation, ie, it's
> > thinking the other index is cheaper to use. Why that is is not clear.
> > Can we see the pg_stats rows for cto
On Wed, 2006-03-15 at 14:17 -0500, Tom Lane wrote:
> It looks to me like this is a matter of bad cost estimation, ie, it's
> thinking the other index is cheaper to use. Why that is is not clear.
> Can we see the pg_stats rows for ctofcNo and calDate?
ISTM that when the BETWEEN constants match we
>>> On Wed, Mar 15, 2006 at 5:05 pm, in message
<[EMAIL PROTECTED]>, Simon Riggs
<[EMAIL PROTECTED]> wrote:
> On Wed, 2006- 03- 15 at 11:56 - 0600, Kevin Grittner wrote:
>
>> (One obvious way to fix it would be to
>> rewrite "BETWEEN a AND b" as "= a" when a is equal to b, but it
seems
>> like t
On Wed, 2006-03-15 at 14:39 -0500, Jan de Visser wrote:
> After fixing the hanging problems I reported here earlier (by uninstalling
> W2K3 SP1), I'm running into another weird one.
>
> After doing a +/- 8hr cycle of updates and inserts (what we call a 'batch'),
> the first 'reporting' type que
Jan de Visser wrote:
Hello,
After fixing the hanging problems I reported here earlier (by uninstalling
W2K3 SP1), I'm running into another weird one.
After doing a +/- 8hr cycle of updates and inserts (what we call a 'batch'),
the first 'reporting' type query on tables involved in that write
On Wed, 2006-03-15 at 11:56 -0600, Kevin Grittner wrote:
> Attached is a simplified example of a performance problem we have seen,
> with a workaround and a suggestion for enhancement (hence both the
> performance and hackers lists).
>
> Our software is allowing users to specify the start and end
On 3/15/06, Andreas Kretschmer <[EMAIL PROTECTED]> wrote:
> Merlin Moncure <[EMAIL PROTECTED]> schrieb:
>
> > On 3/15/06, Kevin Grittner <[EMAIL PROTECTED]> wrote:
> > > Attached is a simplified example of a performance problem we have seen,
> > > with a workaround and a suggestion for enhancement
Merlin Moncure <[EMAIL PROTECTED]> schrieb:
> On 3/15/06, Kevin Grittner <[EMAIL PROTECTED]> wrote:
> > Attached is a simplified example of a performance problem we have seen,
> > with a workaround and a suggestion for enhancement (hence both the
> > performance and hackers lists).
>
>
> Hi Kevi
>>> On Wed, Mar 15, 2006 at 1:54 pm, in message
<[EMAIL PROTECTED]>, "Joshua D. Drake"
<[EMAIL PROTECTED]> wrote:
>> I then did some calculations, based on the sustained write speed of
our
>> drive array (as measured by copying big files to it), and we tried
>> this:
>>
>> bgwriter_lru_percent =
>>> On Wed, Mar 15, 2006 at 1:17 pm, in message
<[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> 8.1 is certainly capable of devising the plan you want, for example
> in the regression database:
>
> regression=# explain select * from tenk1 where thousand = 10 and
tenthous
> between
> I then did some calculations, based on the sustained write speed of our
> drive array (as measured by copying big files to it), and we tried
> this:
>
> bgwriter_lru_percent = 20.0
> bgwriter_lru_maxpages = 200
> bgwriter_all_percent = 10.0
> bgwriter_all_maxpages = 600
>
> This almost totally e
We were seeing clusters of query timeouts with our web site, which were
corrected by adjusting the configuration of the background writer. I'm
posting just to provide information which others might find useful -- I
don't have any problem I'm trying to solve in this regard.
The web site gets 1 to
Hello,
After fixing the hanging problems I reported here earlier (by uninstalling
W2K3 SP1), I'm running into another weird one.
After doing a +/- 8hr cycle of updates and inserts (what we call a 'batch'),
the first 'reporting' type query on tables involved in that write cycle is
very slow. As
On 3/15/06, Kevin Grittner <[EMAIL PROTECTED]> wrote:
> Attached is a simplified example of a performance problem we have seen,
> with a workaround and a suggestion for enhancement (hence both the
> performance and hackers lists).
Hi Kevin. In postgres 8.2 you will be able to use the row-wise
co
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
>> Odd. Can you tell us your PG- Version?
> this is 8.1.2 with some 8.1.3 changes plus the string literal patch.)
8.1 is certainly capable of devising the plan you want, for example
in the regression database:
regression=# explain select * from tenk1
>>> On Wed, Mar 15, 2006 at 12:17 pm, in message
<[EMAIL PROTECTED]>, Andreas Kretschmer
<[EMAIL PROTECTED]> wrote:
> Kevin Grittner <[EMAIL PROTECTED]> schrieb:
>
>> Attached is a simplified example of a performance problem we have
seen,
>
> Odd. Can you tell us your PG- Version?
I know we rea
> I'm a bit puzzled as to how you managed to get so much free space at the
> start of the table. Did the replication work on the second try?
It actually worked on third try, I guess.
> OK, so you might well be getting the vacuum writing one page, then WAL,
> then vacuum, etc. That will mean the
Kevin Grittner <[EMAIL PROTECTED]> schrieb:
> Attached is a simplified example of a performance problem we have seen,
Odd. Can you tell us your PG-Version?
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.
Attached is a simplified example of a performance problem we have seen,
with a workaround and a suggestion for enhancement (hence both the
performance and hackers lists).
Our software is allowing users to specify the start and end dates for a
query. When they enter the same date for both, the opt
Marcin Mańk wrote:
Hello list.
I recently tried to do a slony replica of my database, and doing it falied.
I retried, and then it succeeded (why it failed is another story).
This caused that in the replica there is a lot of dead tuples ( If i
understand correctly, a failure in creating the repl
Hello list.
I recently tried to do a slony replica of my database, and doing it falied.
I retried, and then it succeeded (why it failed is another story).
This caused that in the replica there is a lot of dead tuples ( If i
understand correctly, a failure in creating the replica means a HUGE abor
Jim C. Nasby wrote:
I think you mean this...
http://www.postgresql.org/docs/8.1/static/runtime-config-wal.html
commit_delay (integer)
No, that's not what I mean at all. On a system doing a large number of
WAL-generating transactions per second, it's certainly possible for
multiple transaction
24 matches
Mail list logo
