Greg Smith wrote:
On Wed, 28 May 2008, Josh Berkus wrote:
shared_buffers: according to witnesses, Greg Smith presented at East
that
based on PostgreSQL's buffer algorithms, buffers above 2GB would not
really receive significant use. However, Jignesh Shah has tested
that on
workloads with
Josh Berkus wrote:
Folks,
Subsequent to my presentation of the new annotated.conf at pgCon last week,
there's been some argument about the utility of certain memory settings
above 2GB. I'd like to hash those out on this list so that we can make
some concrete recomendations to users.
shar
On Wed, 28 May 2008, Josh Berkus wrote:
shared_buffers: according to witnesses, Greg Smith presented at East that
based on PostgreSQL's buffer algorithms, buffers above 2GB would not
really receive significant use. However, Jignesh Shah has tested that on
workloads with large numbers of connec
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> sort_mem: My tests with 8.2 and DBT3 seemed to show that, due to
> limitations of our tape sort algorithm, allocating over 2GB for a single
> sort had no benefit. However, Magnus and others have claimed otherwise.
> Has this improved in 8.3?
Simon
Josh Berkus wrote:
Folks,
Subsequent to my presentation of the new annotated.conf at pgCon last week,...
Available online yet? At?...
Cheers,
Steve
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
Folks,
Subsequent to my presentation of the new annotated.conf at pgCon last week,
there's been some argument about the utility of certain memory settings
above 2GB. I'd like to hash those out on this list so that we can make
some concrete recomendations to users.
shared_buffers: according t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Decibel! wrote:
>> If you do this *please* post it. I really think it would be worth
>> while for us to have fixed-size data types for common forms of binary
>> data; MD5, SHA1 and SHA256 come to mind.
> Why do you think it would be worth while?
Giv
Decibel! wrote:
> On Apr 11, 2008, at 10:25 AM, Alvaro Herrera wrote:
>
> Sorry, yes, I'm behind on email... :(
>
> > If MD5 values will be your primary data and you'll be storing millions
> > of them, it would be wise to create your own datatype and operators
> > with
> > the most compact and
I'm interested in the response time instead of the quality of it, that is,
if this response is (or not) a best plan. Thus, my interest on the response
time is to compare the GEQO algorithm with other solutions for optimization
of queries, more specificaly when there are 12 or more tables evolved.
A
On Wed, 2008-05-28 at 13:13 -0300, Tarcizio Bini wrote:
> Of course, the geqo_threshold can be changed so that the geqo be
> performed in queries that have less than 12 tables. However, we aim to
> test the GEQO algorithm in conditions where the standard algorithm
> (dynamic programming) has a hi
Hi,
Of course, the geqo_threshold can be changed so that the geqo be performed
in queries that have less than 12 tables. However, we aim to test the GEQO
algorithm in conditions where the standard algorithm (dynamic programming)
has a high cost to calculate the query plan.
--
Tarcizio Bini
2008
[EMAIL PROTECTED] writes:
> I'm using the TPC-H Benchmark for testing of performance in PostgreSQL.
> But it is composed of only 8 tables, which is not enough to call the GEQO
> algorithm.
See
http://www.postgresql.org/docs/8.3/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-GEQO
particular
Hi all,
I'm using the TPC-H Benchmark for testing of performance in PostgreSQL.
But it is composed of only 8 tables, which is not enough to call the GEQO
algorithm.
I don't want to change any of the 22 queries provided by the TPC-H to call
the GEQO, and not lose the credibility of the TPC's tool.
On Wed, 2008-05-28 at 11:45 +0100, Matthew Wakeling wrote:
> On Tue, 27 May 2008, Simon Riggs wrote:
> > I do recognise that we would *not* be able to deduce this form of SQL
> >
> > A JOIN B ON (a.id = c.id) LEFT JOIN C ON (b.id = c.id)
>
> Surely that would not be valid SQL?
You are right, but
On Tue, 27 May 2008, Simon Riggs wrote:
I do recognise that we would *not* be able to deduce this form of SQL
A JOIN B ON (a.id = c.id) LEFT JOIN C ON (b.id = c.id)
Surely that would not be valid SQL?
Matthew
--
Psychotics are consistently inconsistent. The essence of sanity is to
be inconsi
15 matches
Mail list logo
