Russell Smith <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What is happening is that during that 30-second wait, the bgwriter is
>> dumping out all the dirty pages, and acquiring open file references
>> to each segment of table "foo" as it does so. The VACUUM then truncates
>> "foo" back to ze
On 11/18/06, Rodrigo Hjort <[EMAIL PROTECTED]> wrote:
Dear PG-hackers,
Based on the paper below [1], I ask: is there anyone working on, or already
tried to such native implementation on PostgreSQL? I didn't find anything
related on pgFoundry. There is also a presentation [2] related to the paper
Tom Lane wrote:
While working on fixing the recently reported hash-index problem,
I was using a test build with a very small RELSEG_SIZE (128K),
so that I could trigger the reported bug with a reasonably small
amount of data. And I started finding some unexpected data corruption.
I eventually re
Josh Berkus wrote:
That I don't understand what they're talking about. What's "Ontology" in a
database sense? Can you give some examples?
You'll need to RTFP , which in all fairness the OP did cite in his posting :
http://www.cs.toronto.edu/vldb04/protected/eProceedings/contents/pdf/I
While working on fixing the recently reported hash-index problem,
I was using a test build with a very small RELSEG_SIZE (128K),
so that I could trigger the reported bug with a reasonably small
amount of data. And I started finding some unexpected data corruption.
I eventually reduced it to this t
Matt,
> I now agree completely. My purpose is to migrate Oracle databases to
> Posgres, and I had thought that Oracle didn't support CURRENT_DATE,
> CURRENT_TIMESTAMP, and so on. However, I've just learned otherwise. So,
> I think the proper migration process for a production database would be
>
Rodrigo,
> Besides, what are your opinions on the subject?
That I don't understand what they're talking about. What's "Ontology" in a
database sense? Can you give some examples?
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)
Hi Gurjeet,
I will look at the pg_advise bug and will send a patch ASAP.
Best,
Kai
Am 15.11.2006 um 15:34 schrieb Gurjeet Singh:
BUGS:
=
.) The SELECTs in the pg_advise are returning wrong results, when
the same index is suggested twice, because of the SUM() aggregates.
.) I doubt that o
Alvaro Herrera wrote:
> Oleg Bartunov wrote:
>> On Fri, 17 Nov 2006, Andrew Dunstan wrote:
>
>>> I am also a bit concerned that the names of the proposed objects (parser,
>>> dictionary) don't convey their purpose adequately. Maybe TS_DICTIONARY and
>>> TS_PARSER might be better if we in fact ne
Andrew Dunstan wrote:
> Peter Eisentraut wrote:
>> Oleg Bartunov wrote:
>>> So, if we'll not touch grammar, are there any issues with tsearch2 in
>>> core ?
>> Are there any issues with tsearch2 not in core?
>>
>
>
> Quite apart from anything else, it really needs documentation of the
> standard
Dear PG-hackers,
Based on the paper below [1], I ask: is there anyone working on, or already
tried to such native implementation on PostgreSQL? I didn't find anything
related on pgFoundry. There is also a presentation [2] related to the paper.
"By Souripriya Das, Eugene Inseok Chong, George Eado
On Sat, 18 Nov 2006, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Oleg Bartunov wrote:
So, if we'll not touch grammar, are there any issues with tsearch2 in
core ?
Are there any issues with tsearch2 not in core?
Quite apart from anything else, it really needs documentation of the
standa
Peter Eisentraut wrote:
> Oleg Bartunov wrote:
>> So, if we'll not touch grammar, are there any issues with tsearch2 in
>> core ?
>
> Are there any issues with tsearch2 not in core?
>
Quite apart from anything else, it really needs documentation of the
standard we give other core features.
I thi
> --- Original Message ---
> From: Peter Eisentraut <[EMAIL PROTECTED]>
> To: Jeremy Drake <[EMAIL PROTECTED]>
> Sent: 18/11/06, 07:30:48
> Subject: Re: [HACKERS] Proposal: syntax of operation with tsearch's
> configuration
>
> Jeremy Drake wrote:
> > I am currently in the position that
> > Why should we add this Oraclism to PostgreSQL? I doesn't add any new
> > feature.
>
> Certainly, this feature falls well within the class of completely
> gratuitous proprietary extensions that we typically reject.
I now agree completely. My purpose is to migrate Oracle databases to
Posgres, a
Hi,
Peter Eisentraut wrote:
Are there any issues with tsearch2 not in core?
I have run into troubles when restoring a dump, especially across
different versions of PostgreSQL and tsearch2. Mainly because pg_ts_*
are not system tables and thus need to be restored or installed separately.
An
Simon Riggs wrote:
On Wed, 2006-11-15 at 16:38 -0500, Andrew Dunstan wrote:
My little enumkit tool allows you to create enumerations today very
easily, but its values are completely hardcoded. However, the above
trick still works. The downside is that each enumeration type requires a
tin
> > I found it interesting that gram.c and parse.h already supported SYSDATE.
>
> Only after you ran bison ;-). They're derived files.
Well, so much for my conspiracy theory.
Thanks for the bison lesson.
---(end of broadcast)---
TIP 7: You can he
> I suggest you to contribute this kind of code to orafce project [1]
Thanks, I'll go play over there for a while.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
> > Can't keywords share code
>
> the way to do what you want I think is
> like this:
>
> foo: bar_or_baz
> { code block }
>;
>
> bar_or_baz: bar | baz ;
I'll try that, thanks.
---(end of broadcast)---
TIP 6: explain analyze is your frie
On Fri, Nov 17, 2006 at 11:40:36PM -0500, Tom Lane wrote:
> Stephen Harris <[EMAIL PROTECTED]> writes:
> > Why not, after calling fork() create a new process group with setsid() and
> > then instead of killing the recovery thread, kill the whole process group
> > (-PID rather than PID)? Then every
On Wed, 2006-11-15 at 16:38 -0500, Andrew Dunstan wrote:
> My little enumkit tool allows you to create enumerations today very
> easily, but its values are completely hardcoded. However, the above
> trick still works. The downside is that each enumeration type requires a
> tiny bit of compilati
-- Forwarded message --
From: jorge alberto <[EMAIL PROTECTED]>
Date: Nov 17, 2006 2:09 PM
Subject: Re: [HACKERS] Remove contrib version of rtree_gist --- now in core
system ?
To: Tom Lane <[EMAIL PROTECTED]>
hi !
thanks for writing!
In postgresql version 8.0.9 the rtree_gist imp
Oleg Bartunov wrote:
> So, if we'll not touch grammar, are there any issues with tsearch2 in
> core ?
Are there any issues with tsearch2 not in core?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 3: Have
On Sat, 18 Nov 2006, Simon Riggs wrote:
On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote:
On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
Having the supporting code in core does not make much of a difference
otherwise from having it in contrib, does it?
Given the non
On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote:
> On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
> > > Having the supporting code in core does not make much of a difference
> > > otherwise from having it in contrib, does it?
> >
> > Given the nonextensibility of gram.y
26 matches
Mail list logo
