I'm trying to run some GiST activities and see XLOG record structure.
README tells it runs PG8.2 or later. Does it run with PG8.3beta4?
It seems to depend upon tsearch2 in contrib.
2007/12/20, Teodor Sigaev <[EMAIL PROTECTED]>:
> What kind of benchmark? I have benchmark for text search
> http:/
On Thu, 20 Dec 2007, Gregory Stark wrote:
Surely such machines have kickass memory backplanes too though? How could it
ever be reasonable to have an i/o controller with more bandwidth than your
memory?
Dann had the right general numbers here--max of 6.4GB/s between processors
and you might co
Hello folks,
PGCon 2008 will be held 22-23 May 2008, in Ottawa at the University of
Ottawa. It will be preceded by two days of tutorials on 20-21 May 2008.
We are now requesting proposals for presentations.
If you are doing something interesting with PostgreSQL, please submit
a proposal. You
Tom Lane wrote:
> ...I can believe that suitable test cases would show
> 2X improvement for 2 threads,
One other thing I found interesting is that their test case
showed a near 2X improvement for hyperthreading; where I haven't
heard of many other ways to get hyperthreading to show improvements
f
"Greg Smith" <[EMAIL PROTECTED]> writes:
> On Wed, 19 Dec 2007, Dann Corbit wrote:
>
>> Benchmarking a single system will really only explain that system.
>> Someone may have a disk farm with 2GB/Sec throughput
>> But such a configuration is very unlikely.
>
> If you believe comments like those at
"Dann Corbit" <[EMAIL PROTECTED]> writes:
>> Note that speeding up a query from 20s to 5s isn't terribly useful. If it's
>> OLTP you can't be using all your cores for each user anyways. And if it's
>> DSS 20s isn't a problem.
>
> Unless (of course) there are 20,000 users doing the queries that wou
On Wed, 19 Dec 2007, Dann Corbit wrote:
Benchmarking a single system will really only explain that system.
Someone may have a disk farm with 2GB/Sec throughput
But such a configuration is very unlikely.
If you believe comments like those at
http://www.c0t0d0s0.org/archives/1792-Do-it-yourself
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Gregory Stark
> Sent: Wednesday, December 19, 2007 5:26 PM
> To: Jeff Davis
> Cc: Mark Mielke; Michał Zaborowski; Simon Riggs; Ron Mayer; pgsql-
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS
On Dec 13, 2007, at 7:13 AM, Gregory Stark wrote:
We currently execute a lot of joins as Nested Loops which would be
more
efficient if we could batch together all the outer keys and execute
a single
inner bitmap index scan for all of them together.
Essentially what I'm saying is that we're m
"Jeff Davis" <[EMAIL PROTECTED]> writes:
> test=> explain analyze select * from sorter order by t;
> test=> explain analyze select * from sorter order by b;
> test=> explain analyze select * from sorter order by f;
>
> On my machine this table fits easily in memory (so there aren't any disk
> re
Mark Mielke <[EMAIL PROTECTED]> writes:
> Jeff Davis wrote:
>> Also, there is probably a lot of memory copying going on, and that
>> probably destroys a lot of the effectiveness of L2 caching. When L2
>> caching is ineffective, the CPU spends a lot of time just waiting on
>> memory. In that case, i
On Wed, 2007-12-19 at 15:19 -0800, Dann Corbit wrote:
> The algorithm that I am suggesting will take exactly one pass to merge
> all of the files.
>
>From tuplesort.c:
"In the current code we determine the number of tapes M on the basis of
workMem: we want workMem/M to be large enough that we re
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Updated version attached. Comments on the wording of the messages are also
> welcome ;-)
Well, since you asked ;-) ... I don't particularly like this.
1. Doesn't distinguish SHARING_VIOLATION from LOCK_VIOLATION.
We might want to know that.
2. Do we
P.S.
A beautiful paper on replacement selection is found here:
http://students.fim.uni-passau.de/~fickensc/Proseminar/Proseminar.pdf
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index
> -Original Message-
> From: Jeff Davis [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 19, 2007 3:10 PM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Sorting Improvements for 8.4
>
> On Wed, 2007-12-19 at 14:41 -0800, Dann Corbit wrote:
> > As long as
On Wed, 2007-12-19 at 14:41 -0800, Dann Corbit wrote:
> As long as sorting improvements are being considered, may I suggest an
> experiment that uses a very simple model?
>
> Assuming that you have K subfiles created by the initial sorting pass,
> insert the top record of each file into a priority
On Wed, 2007-12-19 at 15:51 -0500, Mark Mielke wrote:
> That sounds possible, but I still feel myself suspecting that disk
> reads will be much slower than localized text comparison. Perhaps I am
> overestimating the performance of the comparison function?
I think this simple test will change you
As long as sorting improvements are being considered, may I suggest an
experiment that uses a very simple model?
Assuming that you have K subfiles created by the initial sorting pass,
insert the top record of each file into a priority queue.
Then, emit records from the queue until the priority qu
Jeff Davis wrote:
On Wed, 2007-12-19 at 12:08 -0500, Mark Mielke wrote:
Stupid question #2: Is it well recognized that the CPU is the
bottleneck in the PostgreSQL sorting mechanism? Or might it be memory
bandwidth and I/O?
I think it depends a lot on several factors. It's probably a dif
Ron Mayer wrote:
The link in the beginning of the thread points to articles
that seem to describe one such algorithm; along with benchmarks.
(http://tinyurl.com/3bvu4u, http://tinyurl.com/32wg2m)
The improvements were pretty consistent from set sizes ranging
from very small sets (hundreds) to qui
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 19 Dec 2007 13:46:15 -0500
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > > I would suggest forgetting that part and submitting the part
> > > that has some chance of getting accepted.
> >
> >
> > Actually i want to submit the patch, wh
Gokulakannan Somasundaram wrote:
> I would suggest forgetting that part and submitting the part that
> has some chance of getting accepted.
Actually i want to submit the patch, which is best according to me.
That's not an attitude that is likely to succeed - you need to
Mark Mielke wrote:
> I am curious - what algorithms exist to efficiently do a parallel sort?
> Do you mean if sorting 1 million items, it is possible to separate this
> into 2 sets of 500 thousand each, execute them in separate threads
> (with task administration and synchronization overhead) , co
On Wed, 2007-12-19 at 12:08 -0500, Mark Mielke wrote:
> Stupid question #2: Is it well recognized that the CPU is the
> bottleneck in the PostgreSQL sorting mechanism? Or might it be memory
> bandwidth and I/O?
>
I think it depends a lot on several factors. It's probably a different
bottleneck fo
I have submitted the first working patch for the trailing null optimization.
It currently does the following
a) Doesn't store the null bitmap, if the heap tuple / index tuple contains
only trailing nulls
b) In Heap Tuple, the trailing nulls won't occupy space in the null bitmap.
The General design
Michał Zaborowski wrote:
Ok - we want to sort table with quick sort and we want to do it on - N threads.
Every thread - gets begin and end of indices of the table. First step starts
at 0 and lasts with count -1. Single step: find medium value and move
lover before it and bigger after. In normal
I wrote:
> Adding to my suspicion is that I don't recall having seen one of these
> personally,
I take that back --- some digging in my mail logs shows that I have
gotten a few of these, but they went straight to /dev/null because
my spam filters thought they were a virus. Have you checked whethe
On Wed, Dec 19, 2007 at 11:15:37AM -0500, Tom Lane wrote:
> hoping to draw responses from careless people? I've heard of web
> comment-spammers who try to get other people to decode captchas
> for them this way.
Yes. This is the latest spammer trick. They get people all over the globe
to decode
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > It's worse than that in this case. This is an *impressively* broken
> > configuration.
>
> Understatement of the week. The mail includes absolutely no evidence
> about what message is allegedly being filtered. Are you sure that
> th
Gregory Stark <[EMAIL PROTECTED]> writes:
> It's worse than that in this case. This is an *impressively* broken
> configuration.
Understatement of the week. The mail includes absolutely no evidence
about what message is allegedly being filtered. Are you sure that
this is really a filtering engin
Andreas Joseph Krogh <[EMAIL PROTECTED]> writes:
> And remember; Users don't care about portability-issues, they care about
> performance.
Nonsense. If Postgres stops working on their machine, they'll care.
regards, tom lane
---(end of broadcast)
On Wed, Dec 19, 2007 at 04:44:12PM +0100, Magnus Hagander wrote:
> On Wed, Dec 19, 2007 at 04:20:23PM +0100, Zeugswetter Andreas ADI SD wrote:
> >
> > > > Yeah, I think it would be useful to log one message if after (say) 5
> > > > seconds we still haven't been able to open the file.
> > >
> > >
What kind of benchmark? I have benchmark for text search
http://www.sigaev.ru/cvsweb/cvsweb.cgi/ftsbench/
and several others, based on it.
Koichi Suzuki wrote:
Hi,
Does anybody have an information about GiST index benchmark? I'm
planning to run GiST benchmark and analyze WAL structure to see
On Wed, Dec 19, 2007 at 04:20:23PM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > > Yeah, I think it would be useful to log one message if after (say) 5
> > > seconds we still haven't been able to open the file.
> >
> > Either that, or on the first run.
>
> Imho 1-5s is better, so that would be
Zeugswetter Andreas ADI SD wrote:
Yes 0.1 s is imho good. Btw. m$ is talking about milliseconds
(http://support.microsoft.com/kb/316609)
We have seen cases in the past where these locks last quite a long time.
That 30s total timeout in rename and unlink was not chosen arbitrarily -
Zeugswetter Andreas ADI SD wrote:
> > I think not. 0.1 seconds is better. We don't want to delay a full
> > second if it's just a transient thing.
>
> Yes 0.1 s is imho good. Btw. m$ is talking about milliseconds
> (http://support.microsoft.com/kb/316609)
Hm, the article only mentions ERROR_SHA
> > Yeah, I think it would be useful to log one message if after (say) 5
> > seconds we still haven't been able to open the file.
>
> Either that, or on the first run.
Imho 1-5s is better, so that would be after the 10-50th try.
> loop. It's supposed to loop 300 times.
Yes.
> > (Are we OK wi
On Wed, Dec 19, 2007 at 11:23:35AM -0300, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > On Sat, Dec 15, 2007 at 10:31:38PM -0500, Tom Lane wrote:
> > > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > > "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > > >> Interesting. Maybe forever is going a
Magnus Hagander wrote:
> On Sat, Dec 15, 2007 at 10:31:38PM -0500, Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > >> Interesting. Maybe forever is going a bit too far, but retrying for
> > >> seconds or so.
> >
> > > I think lo
On Wed, Dec 19, 2007 at 01:05:00PM +, Gregory Stark wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
>
> > If your software is locking a file for that long, that software is more
> > than just broken, it's horribly broken. Having a workaround against
> > something that might happen once
Alvaro Herrera wrote:
On Wed, Dec 19, 2007 at 01:09:39PM +, Gregory Stark wrote:
If I were the list maintainer here I would ban infotecnica.com.br addresses
from subscribing to any of our lists. Ideally with a message saying "as a
result of misconfigured mail software addreses from inf
On Wed, Dec 19, 2007 at 01:09:39PM +, Gregory Stark wrote:
> If I were the list maintainer here I would ban infotecnica.com.br addresses
> from subscribing to any of our lists. Ideally with a message saying "as a
> result of misconfigured mail software addreses from infotecnica.com.br are
> ba
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Receipt of messages like this is guaranteed an immediate entry in my junk
> filter. Use of this braindead software is bad enough, but being so clueless as
> not to whitelist a technical mailing list you subscribe to is truly horrible.
It's worse than
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> If your software is locking a file for that long, that software is more
> than just broken, it's horribly broken. Having a workaround against
> something that might happen once or twice because of a bug in the other
> software is one thing, but if it
On Sat, Dec 15, 2007 at 10:31:38PM -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> >> Interesting. Maybe forever is going a bit too far, but retrying for
> >> seconds or so.
>
> > I think looping forever is the right thing. Hav
On Sun, Dec 16, 2007 at 10:31:59AM +, Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> >> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> >>> Interesting. Maybe forever is going a bit too far, but retrying for
> >>> seconds or so.
On Fri, Dec 14, 2007 at 10:47:02AM -0500, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >On Fri, Dec 14, 2007 at 03:39:14PM +, Dave Page wrote:
> >
> >>Andrew Dunstan wrote:
> >>
> >>>Writing and calling a temp .bat file might be yucky - having to keep two
> >>>environment files
Gregory Stark wrote:
I'm receiving bogus bounce messages like this (which are malformed even, the
Subject isn't properly encoded). I'm not sure what list is generating them or
what address but if we can figure out who could we drop whoever it is from the
list please?
---
On Tuesday 18 December 2007 10:03:25 Dimitri Fontaine wrote:
> Hi,
>
> Le mardi 18 décembre 2007, Ron Mayer a écrit :
> > Has anyone looked into sorting algorithms that could use
> > more than one CPU or core at a time?
>
> [...]
>
> > PS: Yeah, I know multi-threading is a hot-button on these
> > l
I'm receiving bogus bounce messages like this (which are malformed even, the
Subject isn't properly encoded). I'm not sure what list is generating them or
what address but if we can figure out who could we drop whoever it is from the
list please?
--- Begin Message ---
A mensagem de email en
Ühel kenal päeval, E, 2007-12-17 kell 09:20, kirjutas Simon Riggs:
> On Sat, 2007-12-15 at 13:32 +0100, Albert Cervera i Areny wrote:
> > > Read-Only Tables
> > >
> > > Postgres supports the concept of freezing tuples, so they can live
> > > forever within the database without nee
2007/12/19, Mark Mielke <[EMAIL PROTECTED]>:
> Jeff Davis wrote:
> > My first thought would be that we would need a new executor node (e.g.
> > "ParallelSort") that would only be chosen when the cost of the sort is
> > large enough to outweigh other factors (such as process creation time,
> > divid
Jeff Davis wrote:
My first thought would be that we would need a new executor node (e.g.
"ParallelSort") that would only be chosen when the cost of the sort is
large enough to outweigh other factors (such as process creation time,
dividing available work_mem, and any necessary IPC).
It seems to
53 matches
Mail list logo
