On Mon, 15 Sep 2003 22:26:45 -0400, Christopher Browne
<[EMAIL PROTECTED]> wrote:
>> select count (*) from table;
>The only possible plan for THAT query will involve a seq scan of the
>whole table. If the postmaster already has the data in cache, it
>makes sense for it to run in 1 second. If it h
On 15/09/2003 08:42 Shridhar Daithankar wrote:
Is it possible to follow data type upgrade model in planner? Something
like in
C/C++ where data types are promoted upwards to find out better plan?
int2->int4->int8->float4->float8 types.
That could be a clean solution..
just a thought..
Interesti
...
> #effective_cache_size = 1000# typically 8KB each
That's horribly wrong. It's telling PG that your OS is only likely to cache
8MB of the DB in RAM. If you've got 1GB of memory it should be between
64000 and 96000
---(end of broadcast)-
> "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
TL> I was just bugging Marc for some useful data, so I'll ask you too:
TL> could you provide a trace of the pg_restore execution? log_statement
TL> plus log_duration output would do it. I am curious to understand
TL> exactly which steps in the r
Paul Thomas <[EMAIL PROTECTED]> writes:
> On 15/09/2003 08:42 Shridhar Daithankar wrote:
>> Is it possible to follow data type upgrade model in planner?
We have one, more or less. It's not explicitly coded, it emerges from
the fact that certain casts are implicit and others are not. For
instance
Dear list,
First and foremost, thanks to the great number of people who have responded
with various tips and suggestions. I am now starting to fully appreciate
the various cache settings and what they can do for performance.
I just want to redefine the problem based on the knowledge of it that
On Tue, 16 Sep 2003, Joseph Bove wrote:
> I still think that 3 seconds is not acceptable. However, I reserve the
> right to be wrong. Does it sound unrealistic to expect PostgreSQL to be
> able to read 90,000 rows with 300 bytes per row in under a second?
>
first, check to see what your max throug
Yesterday Jenny and I started to look at plan changes with different
seed and default_statistics_sample changes.
Since we have 21 plans to check, it takes a long time to determine if
the plans were different. We had to do it visually with xxdiff. Diff
will always show a difference since the cos
Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> Is there any option to remove the cost numbers from the plan so we can
> just use "diff" to automate the plan comparisons?
No, but a few moments with sed or perl should get the job done for you.
regards, tom lane
--
