Simon Riggs <[EMAIL PROTECTED]> writes:
> Amdahl's Law tells me that looking at the checkpoints is the next best
> action for tuning, since they add considerably to the average response
> time. Looking at the oprofile for the run as a whole is missing out the
> delayed transaction behaviour that
Some more thoughts and questions.
The main idea above bitmaps is narrowing some data sets' possible values to
"yes" and "no" (i.e. 1 and 0) and then organize the data in the series of
bits, where bit's position determines values to consider. In the cases, where
several indexed attributes are used
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] ("Qu Tianlian")
wrote:
> Hi all:
> I have a question.
> How to add table in slony.
> I try to add table in already being database that using slony . but it's not
> realize table's replication.
> I used postgresql version 7.4.2 and slony
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Also, I have no idea how portable cc -v is.
Not at all.
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
Andrew,
A couple of things,
1. we need to develop a matrix of systems/os/compiler to see what coverage we
do have and compare it to the INSTALL
guide.
2. the run_build.pl should be changed to keep the information on the system to
date (and have the matrix in 1 change)
3. have the run_build.p
> Hello hackers,
>
> i'm wondering if is possible to somehow spread pretty big db (aprox 50G)
> over few boxes to get more speed ?
> if anyone did that i'd be glad to have some directions in right way,
>
I have done different elements of clusering with PostgreSQL on a per task
basis, but not a ful
Simon Riggs <[EMAIL PROTECTED]> writes:
> Checkpoint doesn't request new buffers, but it does require the
> BufMgrLock in order to write all of the dirty buffers.
There is no BufMgrLock anymore in the clock-algorithm code, so I'm not
sure how much of this analysis is still relevant.
On Wed, 2005-03-02 at 20:55 -0500, Tom Lane wrote:
> Michael Adler <[EMAIL PROTECTED]> writes:
> > Looking at the "Response Time Charts"
>
> > 8.0.1/ARC
> > http://www.osdl.org/projects/dbt2dev/results/dev4-010/309/rt.html
>
> > 20050301 with 2Q patch
> > http://www.osdl.org/projects/dbt2dev/res
Darcy Buskermolen wrote:
On Friday 04 March 2005 10:11, Andrew Dunstan wrote:
Now that we've been running for a while there are a few buildfarm issues
that I need to address.
First, do we keep the right data about the members? Essentially, we
keep: . For Linux, we genarlly ask for the
Distribut
On Friday 04 March 2005 10:11, Andrew Dunstan wrote:
> Now that we've been running for a while there are a few buildfarm issues
> that I need to address.
>
> First, do we keep the right data about the members? Essentially, we
> keep: architecture>. For Linux, we genarlly ask for the
> Distribution
Now that we've been running for a while there are a few buildfarm issues
that I need to address.
First, do we keep the right data about the members? Essentially, we
keep: . For Linux, we genarlly ask for the
Distribution/distro-version instead of the OS/os-version. However, that
lead to intere
> [EMAIL PROTECTED] writes:
>> Anyway, IMHO, hash indexes would be dramatically improved if you could
>> specify your own hashing function
>
> That's called a custom operator class.
Would I also be able to query the bucket size and all that?
>
>> and declare initial table size.
>
> It would be in
I am in Copenhagen and am speaking tomorrow and will return on Sunday.
When I return I will get back to the patches queue. I have been delayed
working on my own patches. :-)
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Bruno Wolff III <[EMAIL PROTECTED]> writes:
>>> If K is way low this could be very slow.
>>
>> How so? You're not concerned about the time to do the division itself
>> are you?
> No, rather having lots of entrie
On Fri, Mar 04, 2005 at 10:42:08 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> >> * Estimate the number of batches N using the planner's estimate.
> >> We will always choose N a power of 2. A tuple's batch num
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> * Estimate the number of batches N using the planner's estimate.
>> We will always choose N a power of 2. A tuple's batch number is
>> ((H div K) mod N).
> If K is way low this could be very slow.
How so? You
On Thu, Mar 03, 2005 at 17:05:40 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> * Estimate the number of batches N using the planner's estimate.
> We will always choose N a power of 2. A tuple's batch number is
> ((H div K) mod N).
If K is way low this could be very slow. Is there a way to do
[EMAIL PROTECTED] writes:
> Anyway, IMHO, hash indexes would be dramatically improved if you could
> specify your own hashing function
That's called a custom operator class.
> and declare initial table size.
It would be interesting to see if setting up the hashtable with about
the right number o
Hello hackers,
i'm wondering if is possible to somehow spread pretty big db (aprox 50G) over few boxes to get more speed ?
if anyone did that i'd be glad to have some directions in right way,
thanks and best regard,
Bostjan
Neil Conway <[EMAIL PROTECTED]> writes:
> (BTW, is poor concurrency really the biggest issue with hash indexes? If
> so, there is some low-hanging fruit that I noticed a few years ago, but
> never got around to fixing: _hash_doinsert() write-locks the hash
> metapage on every insertion merely to
Aaron Birkland <[EMAIL PROTECTED]> writes:
> This also brings up a line of thought I had a while ago on a related
> topic. Something like a "HashDistinct" might be useful, if it had no
> startup cost. It would basically be a plan node in the executor that
> would dynamically build a hashtable so
Hello hackers,
> Thanks very much for doing this work. Is there some way you can
> summarize what you did so others can join you in working on it? If it
> is easier for you to write this in some language other than English,
> please do, and we'll find translators :)
>
> I noticed that the patch
On Thursday 03 March 2005 19:08, Neil Conway wrote:
> Thomas F.O'Connell wrote:
> committers, myself included, deserve some blame for not making more
> rapid progress on the queue of unapplied patches for 8.1. In the
> meanwhile, the queue should be easier for folks to find (why is the
> "pgpatches
>While going through the usual motions needed to fork a child
>process of
>the postmaster, it occurred to me that there's a fair bit of
>duplicated
>code involved. There are also #ifdef for various situations (BeOS,
>LINUX_PROFILE, and EXEC_BACKEND), which makes the code yet
>more ugly. I
>t
> Pailloncy Jean-Gerard wrote:
>> You should have a look to this thread
>> http://archives.postgresql.org/pgsql-hackers/2005-02/msg00263.php
>>
>> Take a look at this paper about "lock-free parallel hash table"
>> http://www.cs.rug.nl/~wim/mechver/hashtable/
>
> Is this relevant? Hash indexes are o
Pailloncy Jean-Gerard wrote:
You should have a look to this thread
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00263.php
Take a look at this paper about "lock-free parallel hash table"
http://www.cs.rug.nl/~wim/mechver/hashtable/
Is this relevant? Hash indexes are on-disk data structure
Le 2 mars 05, à 21:17, Hannu Krosing a écrit :
Ühel kenal päeval (teisipäev, 1. märts 2005, 14:54-0500), kirjutas
[EMAIL PROTECTED]:
Now, it occurs to me that if my document reference table can refer to
something other than an indexed primary key, I can save a lot of index
processing time in Postgr
27 matches
Mail list logo
