indexes, then it must use operator number so-and-so for equality. But
there are lots of GiST opclasses that don't include equality at all; we
can't break that case.
There is a GiST support function for equality of keys, in btree_gist it's named
as gbt_*_same. Equality function has support numb
Ühel kenal päeval, E, 2007-02-12 kell 17:23, kirjutas Heikki
Linnakangas:
> [EMAIL PROTECTED] wrote:
> > On Mon, Feb 12, 2007 at 12:48:06AM -0500, Tom Lane wrote:
> >> We just finished sweating blood to get the tuple header size down to 23
> >> bytes from 27 (which saves 8 bytes not 4 if MAXALIGN=8
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Lukas Kahwe Smith wrote:
>>> http://developer.postgresql.org/index.php/IRC2RWNames
>>
>> Ah, excellent. Should we put this in the IRC topic line?
> if there is still some space in the topic ... sure!
Is there any cross-chec
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Hi,
I know this is slightly off topic, but I hope still useful enough to not
get my head cut off for posting this:
http://developer.postgresql.org/index.php/IRC2RWNames
This is essentially a mapping of IRC nicks to real world names. While
mainta
"Matthew Campbell" <[EMAIL PROTECTED]> writes:
> I've been working with a group trying to
> implement UNIQUE index functionality in GiST
> ... but we can't figure out how to
> compare the two datums then. The actual data type of the value being
> inserted would be different depending on the type o
Gregory Stark <[EMAIL PROTECTED]> writes:
> Do you see any way to avoid having every user function everywhere
> use a new macro api instead of VARDATA/VARATT_DATA and VARSIZE/VARATT_SIZEP?
Bruce and I had a long phone conversation about that today. We
concluded that there doesn't seem to be any s
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> Actually, I think we should completely separate the namespaces of the
>>> global transaction identifiers, so that you could use the same gid in
>>> two different databases without a conflict.
>>
>> Really? They're supposed to
On Saturday 10 February 2007 13:59, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I'd say we probably want to keep the tgargs info for at least a version
> > or two after changing the implementation. Getting rid of using the args
> > info sounds like a good idea.
>
> We whack the
I wrote:
> I looked into Ian Harding's problem reported here:
> http://archives.postgresql.org/pgsql-general/2007-02/msg00530.php
I've applied the attached patch, but it could do with some more
testing. Please try it out on your database and see if you get sane
answers ...
As suggested, the result I've posted used standard checkpoint_timeout.
With longer checkpoint timeout, overall WAL size tend to decrease. So
I've also run DBT-2. The measurement shows that the resultant WAL size
is reasonably small, while preserving full page writes to WAL,
maintaining the
I got a private email from Claudio saying he already answered this
question:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00285.php
I forgot I saw it, so I have added comments to the C code.
---
bruce wr
Further, because pgbench writes many zero values to fixed length
columns, gzip can achieve better compression. There're another
suggestion to test with longer checkpoint interval. I will post the
result.
Thanks.
Martijn van Oosterhout wrote:
> On Fri, Feb 09, 2007 at 01:00:10PM +0900, Koichi
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I think #1, while ugly, is probably less ugly than the others, although I
> guess it means even more work if the underlying type of the column is
> changed.
Oy, I hadn't thought of that. [ considers... ] I *think* that it'll
work without special code,
Lukas Kahwe Smith wrote:
> Hi,
>
> I know this is slightly off topic, but I hope still useful enough to not
> get my head cut off for posting this:
> http://developer.postgresql.org/index.php/IRC2RWNames
>
> This is essentially a mapping of IRC nicks to real world names. While
> maintaining the
On Mon, 12 Feb 2007, Tom Lane wrote:
> I wrote:
> >> * Add an oid[] column to pg_constraint that stores the equality operator
> >> OIDs for a foreign-key constraint, in the same column order as conkey[]
> >> and confkey[].
>
> It turns out this isn't sufficient: ri_Check_Pk_Match() wants to
> gene
Gene,
I think tmpfs/ramfs method would increase the performance of PostgreSQL
when workload is write-intensive.
Does pgbench issue write intensive queries ? Since I do not know the
detailed queries issued in pgbench, I am happy if you teach me.
Regards,
-- Hideyuki
Gene wrote:
I was curiou
Peter Eisentraut wrote:
> Jeroen T. Vermeulen wrote:
>> Is this a known problem? Is there any test procedure that builds the
>> "base" distribution before release?
>
> Most of the core team is convinced that the postgresql-foo tarballs are
> useless, but Marc insists on keeping them. But since
Hideyuki Kawashima wrote:
> Bruce,
>
> Thanks for your comments, and let me answer to your question.
> Sigres is *not* significantly faster than just creating a file system on
> the permanent memory and putting xlog on there.
> Sigres is slightly faster than the case because each backend does not
Bruce,
Thanks for your comments, and let me answer to your question.
Sigres is *not* significantly faster than just creating a file system on
the permanent memory and putting xlog on there.
Sigres is slightly faster than the case because each backend does not
call XLogWrite while bgWriter does.
On Sunday 11 February 2007 05:59, Martijn van Oosterhout wrote:
> On Sat, Feb 10, 2007 at 12:20:35PM -0500, Tom Lane wrote:
> > I do
> > agree with adding a test when you think it is likely to be able to catch
> > a whole class of errors, or even a specific error if it seems especially
> > likely
On Mon, 12 Feb 2007, Tom Lane wrote:
> Jeremy Drake <[EMAIL PROTECTED]> writes:
> > On Mon, 12 Feb 2007, Teodor Sigaev wrote:
> >> Fix backend crash in parsing incorrect tsquery.
>
> > Is this a security issue? Does it need a new security release?
>
> We looked at this and determined that the wor
Gene <[EMAIL PROTECTED]> writes:
> I was curious to see how postgres would perform with wal on a tmpfs vs disk
> here are some numbers I got from pgbench. Let me know if I did something
> stupid, this is the first time I've used pgbench. The wal on tmpfs method is
> not significantly faster.
This
Jeremy Drake <[EMAIL PROTECTED]> writes:
> On Mon, 12 Feb 2007, Teodor Sigaev wrote:
>> Fix backend crash in parsing incorrect tsquery.
> Is this a security issue? Does it need a new security release?
We looked at this and determined that the worst that could be done with
it is crash the backend
On Tue, 13 Feb 2007, Peter Eisentraut wrote:
> We don't treat crashes to be security issues of the kind that calls for
> the full security exercise.
But if a "security issue", by whatever definition of the term applies to
core, is found in contrib, it would result in the full security exercise,
c
Jeremy Drake wrote:
> On Mon, 12 Feb 2007, Teodor Sigaev wrote:
> > Log Message:
> > ---
> > Fix backend crash in parsing incorrect tsquery.
> >
> > Per report from Jon Rosebaugh <[EMAIL PROTECTED]>
>
> Is this a security issue? Does it need a new security release?
We don't treat crashes
On 2/12/07, Gene <[EMAIL PROTECTED]> wrote:
I was curious to see how postgres would perform with wal on a tmpfs vs
disk here are some numbers I got from pgbench. Let me know if I did
something stupid, this is the first time I've used pgbench. The wal on tmpfs
method is not significantly faster.
Tommy Gildseth wrote:
> How do you define the table name when fetching data using a join,
> union etc. where the data doesn't necessarily originate from a single
> table?
If you use the query_to_xml function, then I just write ""
without any particular name.
> Another neat feature would be if yo
On Mon, 12 Feb 2007, Teodor Sigaev wrote:
> Log Message:
> ---
> Fix backend crash in parsing incorrect tsquery.
>
> Per report from Jon Rosebaugh <[EMAIL PROTECTED]>
Is this a security issue? Does it need a new security release? I hope
that the answer is not "this is contrib, it isn't
> > Currently tsearch2 does not accept non ascii stop words if locale is
> > C. Included patches should fix the problem. Patches against PostgreSQL
> > 8.2.3.
>
> I'm not sure about correctness of patch's description.
>
> First, p_islatin() function is used only in words/lexemes parser, not
> st
Peter Eisentraut wrote:
tableforest = false gives you something like
...
tableforest = true gives you something like
...
...
...
How do you define the table name when fetching data using a join, union
etc. where the data doesn't necessarily originate from a single table?
Could
Tom Lane wrote:
> There is no "-base version". The split tarballs are a convenience
> for downloading over slow lines; it is not intended that you can
> build after downloading just some of them.
It used to be possible to build at least the -base tarball
independently. But again, none of this w
Andrew Dunstan wrote:
> . table_to_xml_and_xmlschema seems like a mouthful - can we shorten
> it a bit?
Well, it gives you back a mouthful of data, too. :)
> . what are the two ways of representing data that tableforest
> distinguishes?
tableforest = false gives you something like
data
I was curious to see how postgres would perform with wal on a tmpfs vs disk
here are some numbers I got from pgbench. Let me know if I did something
stupid, this is the first time I've used pgbench. The wal on tmpfs method is
not significantly faster.
[[ WAL ON TMPFS ]]
pgbench -i -s 10 -U postgr
Tom Lane wrote:
> Gene <[EMAIL PROTECTED]> writes:
> > ... just my two cents. on a side note, would putting the wal on a
> > tmpfs partition give you something similar?
>
> Indeed, I'm wondering why one needs to hack the Postgres core to throw
> away data integrity guarantees; there are plenty of
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> I built the "-base" version of 8.2.3 today, for installation at a company
> I'm helping out.
There is no "-base version". The split tarballs are a convenience for
downloading over slow lines; it is not intended that you can build after
downloadi
I looked into Ian Harding's problem reported here:
http://archives.postgresql.org/pgsql-general/2007-02/msg00530.php
It's possible to reproduce the problem in a simplified form in the
regression database, using this query:
explain
select * from
tenk1 a left join
(tenk1 b inner join
(t
Hey folks:
I posted this to the pgsql-novice mailing list but was told that it'd
probably be better to repost here. I've been working with a group trying to
implement UNIQUE index functionality in GiST (we started with hash, and have
branched out to try and understand some of the other indexi
Hi,
I know this is slightly off topic, but I hope still useful enough to not
get my head cut off for posting this:
http://developer.postgresql.org/index.php/IRC2RWNames
This is essentially a mapping of IRC nicks to real world names. While
maintaining the wishlist I keep forgetting the IRC nic
Peter Eisentraut wrote:
Here are the proposed signatures for the XML export functions.
While I have seen the output formats in use elsewhere, I could not find
any useful information on how to invoke these mappings, so the
following is purely my own invention.
table_to_xml(tbl regclass, nulls
Here are the proposed signatures for the XML export functions.
While I have seen the output formats in use elsewhere, I could not find
any useful information on how to invoke these mappings, so the
following is purely my own invention.
table_to_xml(tbl regclass, nulls boolean, tableforest boolean
On Tue, February 13, 2007 01:45, Peter Eisentraut wrote:
> Most of the core team is convinced that the postgresql-foo tarballs are
> useless, but Marc insists on keeping them. But since they are nearly
> useless, no one tests them, so it is not surprising that they don't
> work.
Well, hurray for
Jeroen T. Vermeulen wrote:
> Is this a known problem? Is there any test procedure that builds the
> "base" distribution before release?
Most of the core team is convinced that the postgresql-foo tarballs are
useless, but Marc insists on keeping them. But since they are nearly
useless, no one t
I built the "-base" version of 8.2.3 today, for installation at a company
I'm helping out. The build (and later, the installation) gave me an error
about a missing directory "test/regress". IIRC I downloaded
ftp://ftp.us.postgresql.org/pub/mirrors/postgresql/source/v8.2.3/postgresql-base-8.2.3.ta
Hi,
I have made a Sigres which accelerates INSERT/UPDATE on PostgreSQL using
UPS.
The philosophy of Sigres is considering a battery supplied memory as a
persistent device, instead of disk.
You can download it from http://sourceforge.jp/projects/sigres/ .
In my environment, Sigres is 7 times faste
On Friday 09 February 2007 08:16, Doug Knight wrote:
> I would also be interested in any "creative" ways to reduce the size and
> time to backup databases/clusters. We were just having a conversation
> about this yesterday. We were mulling over things like using rsync to
> only backup files in the
I've been looking at this again and had a few conversations about it. This may
be easier than I had originally thought but there's one major issue that's
bugging me. Do you see any way to avoid having every user function everywhere
use a new macro api instead of VARDATA/VARATT_DATA and VARSIZE/VAR
Tom Lane wrote:
Actually, I think we should completely separate the namespaces of the
global transaction identifiers, so that you could use the same gid in
two different databases without a conflict.
Really? They're supposed to be "global".
Well yeah, the TM should be assigning globally uni
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Do we consider committing a transaction from another database a feature,
> and fix NOTIFY/LISTEN, or should COMMIT PREPARED throw an error if
> you're not connected to the same database?
Hmm ... if we were sure NOTIFY were the only sore spot I'd s
Christopher Browne wrote:
> [EMAIL PROTECTED] (Hideyuki Kawashima) wrote:
>> Joshua,
>>
>> I appreciate your quick & informative reply. And, I also really
>> appreciate your kind comments. Since I have joined this ML 3 hours
>> ago, I tried to be polite and slightly nervous. But I was relieved
>> b
[EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2007 at 12:48:06AM -0500, Tom Lane wrote:
We just finished sweating blood to get the tuple header size down to 23
bytes from 27 (which saves 8 bytes not 4 if MAXALIGN=8). We are not
going to blow that again on HOT.
I haven't had enough time to follow a
Alvaro Herrera wrote:
I think we should set things up so that prepared transactions are
dropped when they concern a database being dropped. Opinions?
Agreed, if you want to drop the database, you don't care about the
transactions in it anymore.
It seems straightforward to implement. We'll n
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think we should set things up so that prepared transactions are
> dropped when they concern a database being dropped. Opinions?
No. A prepared transaction is one that we have guaranteed we can commit
when the 2PC manager tells us to. Reneging on th
I was just testing autovac once more, and happened to Ctrl-C the
regression run in the prepared_xacts test. Upon starting Postmaster
again, I see this:
LOG: recovering prepared transaction 14372
LOG: recovering prepared transaction 14377
Then, I reran "make check", and got
== dro
Currently tsearch2 does not accept non ascii stop words if locale is
C. Included patches should fix the problem. Patches against PostgreSQL
8.2.3.
I'm not sure about correctness of patch's description.
First, p_islatin() function is used only in words/lexemes parser, not stop-word
code. Second
On Mon, Feb 12, 2007 at 12:48:06AM -0500, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > How about adding a new 2-byte field to header for in-page c_tid poiner
> > for HOT ?
> We just finished sweating blood to get the tuple header size down to 23
> bytes from 27 (which saves 8 byt
On 2/11/07, Jaime Casanova <[EMAIL PROTECTED]> wrote:
On 2/11/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jaime Casanova" <[EMAIL PROTECTED]> writes:
> > just for curiosity, why the code doesn't throw an error when using
> > sequences in the from_list of a select?
>
> That's a feature, not a bug.
> > > What are the problems with just shuffling the last (and only
visible)
> > > tuple to replace the HOT-hain root and be done with it ?
> >
> > ctid stops being a reliable identifier.
A backend selecting the row by ctid would need to take one step to
the root slot to get at the tuple. This d
I made some notes about what you said about my patch, just so that I can
be sure that it is clear what it does.
On Sun, 11 Feb 2007, David Fetter wrote:
> == PostgreSQL Weekly News - February 11 2007 ==
>
> == Pending Patches ==
>
> Jeremy Drake sent in a patch which implements regexp_replace wit
58 matches
Mail list logo
