Hi,
Does anybody have an information about GiST index benchmark? I'm
planning to run GiST benchmark and analyze WAL structure to see PG's
dynamic behavior.
Regards;
--
Koichi Suzuki
---(end of broadcast)---
TIP 3: Have you checked our extensi
Greg Smith <[EMAIL PROTECTED]> writes:
> On Wed, 19 Dec 2007, KaiGai Kohei wrote:
>> It seems to me this check enforces us to use autoconf 2.59, not the latest
>> one.
>> Is there any reason for this change?
> The brutally long thread at
> http://archives.postgresql.org/pgsql-hackers/2007-11/msg
Andrew, Greg, Thanks for your infomation.
I've skimed through the thread.
It seems to me that using autoconf-2.59 and applying a patch to pre-built
configure is the most appropriate way to add an original configure option.
Thanks,
Greg Smith wrote:
On Wed, 19 Dec 2007, KaiGai Kohei wrote:
It
KaiGai Kohei wrote:
> Andrew Dunstan wrote:
>
>> KaiGai Kohei wrote:
>>
>>> I found a tiny fix for configure.in at Nov 26.
>>>
>>> http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h
>>>
>>> It seems to me this check enforces us to use autoconf 2.59, n
On Wed, 19 Dec 2007, KaiGai Kohei wrote:
It seems to me this check enforces us to use autoconf 2.59, not the latest one.
Is there any reason for this change?
2.59 is the stable version of autoconf PostgreSQL 8.3 is built against,
and the check keeps anyone from accidentally running it against
"Decibel!" <[EMAIL PROTECTED]> writes:
> When a read() call returns, surely the kernel knows whether it actually
> issued
> a physical read request to satisfy that. I don't see any reason why you
> couldn't have a version of read() that returns that information. I also
> rather
> doubt that
Andrew Dunstan wrote:
>
> KaiGai Kohei wrote:
>> I found a tiny fix for configure.in at Nov 26.
>>
>> http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h
>>
>> It seems to me this check enforces us to use autoconf 2.59, not the latest
>> one.
>> Is there any r
KaiGai Kohei wrote:
> I found a tiny fix for configure.in at Nov 26.
>
> http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h
>
> It seems to me this check enforces us to use autoconf 2.59, not the latest
> one.
> Is there any reason for this change?
>
> For e
On Dec 18, 2007, at 3:32 AM, Gregory Stark wrote:
Also, has anyone looked into adding a class of system calls that
would
actually tell us if the kernel issued physical IO? I find it hard
to believe
that other RDBMSes wouldn't like to have that info...
Yeah, I think that's called "DTrace"
I found a tiny fix for configure.in at Nov 26.
http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in.diff?r1=1.537;r2=1.538;f=h
It seems to me this check enforces us to use autoconf 2.59, not the latest one.
Is there any reason for this change?
For example, autoconf 2.61 is installed in
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
>>I have currently completed the following
>> a) If there are only trailing nulls in the heap, no null-bitmap gets stored
>> b) If there are trailing nulls in addition to nulls inbetween values in
On Tue, 2007-12-18 at 09:31 +, Simon Riggs wrote:
> On Mon, 2007-12-17 at 16:34 -0800, Ron Mayer wrote:
>
> > PS: Yeah, I know multi-threading is a hot-button on these
> > lists; but sorting seems a relatively isolated of the code
> > and I'd wonder if it'd be isolate-able enough that multiple
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
>I have currently completed the following
> a) If there are only trailing nulls in the heap, no null-bitmap gets stored
> b) If there are trailing nulls in addition to nulls inbetween values in the
> heap, then the trailing nulls are not a
Hi,
I have currently completed the following
a) If there are only trailing nulls in the heap, no null-bitmap gets stored
b) If there are trailing nulls in addition to nulls inbetween values in the
heap, then the trailing nulls are not added to the null-bitmap. I wouldn't
have done it, but it cam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 18 Dec 2007 12:09:28 +0300 (MSK)
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
> Our situation is different, we have involved into many
> postgres-related projects, some of them rather popular and we have
> permanent pressure from users to improve,
On Dec 18, 2007 11:30 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Chernow <[EMAIL PROTECTED]> writes:
> > When dealing with binary, the Oid the client sends may match what the
> > server thinks but the data is wrong (client sent binary formatted data
> > of the wrong type). Thus, the only rea
On Dec 12, 2007, at 1:26 PM, Markus Schiltknecht wrote:
Josh Berkus wrote:
Sure. Imagine you have a 5TB database on a machine with 8 cores
and only one concurrent user. You'd like to have 1 core doing I/
O, and say 4-5 cores dividing the scan and join processing into
4-5 chunks.
Ah, righ
On Dec 11, 2007, at 7:50 AM, Trevor Talbot wrote:
I've actually been wanting this lately, for a couple reasons. One is
reduced disk footprint, but the other is reduced I/O, similar to how
TOAST helps with large fields now. (In my particular scenario, TOAST
can't help due to small field sizes.)
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Dec 18, 2007 at 02:48:23PM +0100, [EMAIL PROTECTED] wrote:
>> But then, I still don't get the relationship between
>>
>> INNER, OUTER varnos on the one side and
>> ecxt_scantuple, ecxt_outertuple and ecxt_innertuple on the other side.
>
Andrew Chernow <[EMAIL PROTECTED]> writes:
> When dealing with binary, the Oid the client sends may match what the
> server thinks but the data is wrong (client sent binary formatted data
> of the wrong type). Thus, the only real check we saw was on the data
> length (which is rolling the dice)
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Both array and record binary recv functions require that the recv'd Oid
match the Oid of what the backend has deduced. We don't think this
behavior gets you very much.
Other than the ability to detect errors before the code goes off
Sebastien FLAESCH wrote:
Thank you Andrew,
I agree the example is a bit confusing, anyway it's my fault...
problem fixed.
However, could you please confirm that I can use the same name for a
prepared statement and a server cursor?
Your example would have failed earlier otherwise.
Ple
Andrew Chernow <[EMAIL PROTECTED]> writes:
> Both array and record binary recv functions require that the recv'd Oid
> match the Oid of what the backend has deduced. We don't think this
> behavior gets you very much.
Other than the ability to detect errors before the code goes off into
the weed
>> PQlookupOid(PGconn *conn, char **type_names, Oid *oids, int count);
We are backing away from this (not such a great idea). We are actually
working hard at removing Oid dependencies from our PGparam idea. We
think it is more generic to make the server allow InvalidOid for
composites and ar
On Tue, Dec 18, 2007 at 02:48:23PM +0100, [EMAIL PROTECTED] wrote:
> But then, I still don't get the relationship between
>
> INNER, OUTER varnos on the one side and
> ecxt_scantuple, ecxt_outertuple and ecxt_innertuple on the other side.
>
> May a non-leaf node refer to a Var with a 'normal'
Both array and record binary recv functions require that the recv'd Oid
match the Oid of what the backend has deduced. We don't think this
behavior gets you very much. The backend apparently knows the Oid of a
composite or array elemtype, so if the sender chooses to send InvalidOid
why should
Just realised I posted this to the wrong address last time...
I've been playing around with the new integrated tsearch2 stuff, and it
all seems to work just fine.
However, if you define an external dictionary file (in my case a list of
half-a-dozen stopwords) then obviously pg_dump can't dump
Thank you Andrew,
I agree the example is a bit confusing, anyway it's my fault... problem fixed.
However, could you please confirm that I can use the same name for a prepared
statement and a server cursor?
This seems to work:
test1=> declare s1 cursor with hold for select * from dbit2;
test1=
On Tue, Dec 18, 2007 at 09:32:51AM -0300, Alvaro Herrera wrote:
> Martijn van Oosterhout wrote:
> > On Mon, Dec 17, 2007 at 01:48:31PM +, Alvaro Herrera wrote:
> > > Log Message:
> > > ---
> > > Improve wording.
>
> I agree that the parenthised phrase should be removed.
>
> http://dev
Sorry I should have double checked, it's my fault.
I do not CLOSE the cursor before the third PQexecPrepare()...
Never mind.
Seb
Sebastien FLAESCH wrote:
Hi All,
I am new to this mailing list and want to participate to the 8.3.0 beta
program.
(Sorry to be late BTW)
My name is Sebastien FLA
2007/12/16, Tom Lane <[EMAIL PROTECTED]>:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > But can't we _define_ such a subset, where we can do a transactionless
> > load ?
>
> Sure ... but you'll find that it's not large enough to be useful.
> Once you remove all the interesting consistency checks
Sebastien FLAESCH wrote:
Hi All,
I am new to this mailing list and want to participate to the 8.3.0
beta program.
(Sorry to be late BTW)
My name is Sebastien FLAESCH and I am in charge of the database
interfaces at Four J's Development Tools.
Our product is a Informix 4gl compatible comp
Hi All,
I am new to this mailing list and want to participate to the 8.3.0 beta program.
(Sorry to be late BTW)
My name is Sebastien FLAESCH and I am in charge of the database interfaces at
Four J's Development Tools.
Our product is a Informix 4gl compatible compiler / runtime system.
I wrote
Thanks Tom,
that made it clear I made a mistake.
> That's the way it's supposed to be --- the scantuple slot is for
> scanning your subplan's output.
Browsing through the code I get the impression, that
- ecxt_scantuple is only used by Scan nodes (i.e. SeqScan, IndexScan,
SubqueryScan and Fun
Martijn van Oosterhout wrote:
> On Mon, Dec 17, 2007 at 01:48:31PM +, Alvaro Herrera wrote:
> > Log Message:
> > ---
> > Improve wording.
> I'd suggest removing everything between the parentheses, or perhaps
> something like: By tracking allocated memory rather than used memory
> it r
"Decibel!" <[EMAIL PROTECTED]> writes:
> Also, has anyone looked into adding a class of system calls that would
> actually tell us if the kernel issued physical IO? I find it hard to believe
> that other RDBMSes wouldn't like to have that info...
Yeah, I think that's called "DTrace"
--
Greg
On Mon, 2007-12-17 at 16:34 -0800, Ron Mayer wrote:
> PS: Yeah, I know multi-threading is a hot-button on these
> lists; but sorting seems a relatively isolated of the code
> and I'd wonder if it'd be isolate-able enough that multiple
> CPUs could be used there.
I'm not sure multi-threading is th
On Mon, 17 Dec 2007, Merlin Moncure wrote:
On Dec 17, 2007 3:23 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Oleg Bartunov wrote:
On Mon, 17 Dec 2007, Magnus Hagander wrote:
just interested do we have a place where developers could post
their availability for contract work ?
For example
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
> lists; but sorting seems a relatively isolated of the code
> and I'd wonder if it
39 matches
Mail list logo
