Added to TODO:
* Add RESET CONNECTION command to reset all session state
This would include resetting of all variables (RESET ALL), dropping of
all temporary tables, removal of any NOTIFYs, etc. This could be used
for connection pooling. We could also change RESET ALL to have this
func
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] transmitted:
> I am doing a comparison between MySQL and PostgreSQL.
>
> In the MySQL manual it says that MySQL performs best with Linux 2.4 with
> ReiserFS on x86. Can anyone official, or in the know, give similar
> informatio
Tim,
> In the MySQL manual it says that MySQL performs best with Linux 2.4 with
> ReiserFS on x86. Can anyone official, or in the know, give similar
> information regarding PostgreSQL?
PostgreSQL runs on a lot more platforms than MySQL; it's not even reasonable
to compare some of them, like rtLi
On Tue, 12 Oct 2004 [EMAIL PROTECTED] wrote:
In the MySQL manual it says that MySQL performs best with Linux 2.4 with
ReiserFS on x86. Can anyone official, or in the know, give similar
information regarding PostgreSQL?
Don't know which OS/filesystem PostgreSQL runs best on, but you should
test on
In the MySQL manual it says that MySQL performs best with Linux 2.4 with
ReiserFS on x86. Can anyone official, or in the know, give similar
information regarding PostgreSQL?
I'm neither official, nor in the know, but I do have a spare moment! I
can tell you that any *NIX variant on any modern
Hello
I am doing a comparison between MySQL and PostgreSQL.
In the MySQL manual it says that MySQL performs best with Linux 2.4 with
ReiserFS on x86. Can anyone official, or in the know, give similar
information regarding PostgreSQL?
Also, any links to benchmarking tests available on the interne
On Tue, Oct 12, 2004 at 04:29:36PM +0200, Gabriele Bartolini wrote:
> FYI I set it to 1000 (the maximum) and I reduced the query's estimated time
> by the 90% (from 4ms to 4000ms) although much slower than the index
> scan (200ms).
Note that the estimated times are _not_ in ms. They are in mul
Hi Kris,
>I believe the problem is that pg's lack of cross-column statistics is
>producing the poor number of rows estimate. The number of rows mataching
I got your point now. I had not understood it last night but it makes really
sense.
>which is roughtly 10% of the table. I imagine the query
my ho <[EMAIL PROTECTED]> writes:
> If anyone can help pls, I have a question abt the
> execution of cursor create/fetch/move , in particular
> about disk cost. When a cursor is created, is the
> whole table (with the required columns) got put into
> memory?
No. The plan is set up and then increm
Pierre-Frédéric Caillaud mentioned :
=> http://www.postgresql.org/docs/7.4/static/jdbc-query.html#AEN24298
My question is :
Is this only true for postgres versions >= 7.4 ?
I see the same section about "Setting fetch size to turn cursors on and off"
is not in the postgres 7.3.7 docs. Does this me
I just discovered this :
http://www.postgresql.org/docs/7.4/static/jdbc-query.html#AEN24298
On Tue, 12 Oct 2004 04:43:43 -0700 (PDT), my ho <[EMAIL PROTECTED]>
wrote:
Hi,
If anyone can help pls, I have a question abt the
execution of cursor create/fetch/move , in particular
about disk cost.
Makes sense. See DB2 8.2 info on their new implementation of cross column
statistics. If this is common and you're willing to change code, you can
fake that by adding a operation index on some hash function of both columns,
and search for both columns and the hash.
- Original Message -
Fr
Hi,
If anyone can help pls, I have a question abt the
execution of cursor create/fetch/move , in particular
about disk cost. When a cursor is created, is the
whole table (with the required columns) got put into
memory? otherwise how does it work? (in term of disk
read and transfer?) after user iss
13 matches
Mail list logo
