3-gram is implemented as a contrib/pg_trgm. It currently uses GiST index,
but may be enhanced with the GiN.
Oleg
On Sat, 17 Feb 2007, Tatsuo Ishii wrote:
Hi,
Is anybody working on implementing n-gram search functionality for
text type data? tsearch2 is great for long text but it's not
appropr
On Fri, 16 Feb 2007, Alvaro Herrera wrote:
Jim C. Nasby wrote:
My suggestion would be to focus on a period data type first and
foremost, as that's something that could be readily used by a lot of
folks. Of particular note, it's difficult to query tables that have
start_time and end_time fields
On 2/17/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Bruce Momjian escribió:
> Maybe now would be an appropriate time to discuss the open questions in
> the submitting email:
> > Brendan Jurd wrote:
> > > I'd also like to raise the topic of how conversion from text to ISO
> > > week dates shou
Pavel Stehule wrote:
> Hello
>
> please add to ToDo: Holdable cursor support in SPI
Added:
* Allow holdable cursors in SPI
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a
Alvaro Herrera wrote:
>
> Once autovacuum_naptime... autovacuum_max_workers...
> How does this sound?
The knobs exposed on autovacuum feel kinda tangential to
what I think I'd really want to control.
IMHO "vacuum_mbytes_per_second" would be quite a bit more
intuitive than cost_delay, naptime, et
Added to TODO under PL/pgSQL:
o Allow row and record variables to be set to NULL constants,
and allow NULL tests on such variables
Because a row is not scalar, do not allow assignment
from NULL-valued scalars.
--
I need someone to review this patch to make sure the API used is
logical. You can do that by reading the README file in the patch. To
me, the procedure seems overly complicated, and too restrictive.
The patch is in the patches queue.
I have completed processing of the 8.3 patches "hold" queue. There are
some emails where I am waiting on a reply from the authors, but I will
now just handle them as part of the normal patch process.
I will now return to processing patches as they come in, and deal with
the patches that are now w
Hi,
Is anybody working on implementing n-gram search functionality for
text type data? tsearch2 is great for long text but it's not
appropreate for short (10-100 bytes) text data. What I want to achieve
is a fast partial match search using indexes, i.e. foo ~ 'bar' or foo
LIKE '%bar%' type matchin
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Each worker, including the initial one, starts vacuuming tables
> according to pgstat data. They recheck the pgstat data after finishing
> each table, so that a table vacuumed by another worker is not processed
> twice (maybe problematic: a table with h
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> When there is a single worker processing a database, it does not recheck
> pgstat data after each table. This is to prevent a high-update-rate
> table from starving the vacuuming of other databases.
This case is important; I don't think that having mul
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
On first blush, I'm not sure I like this as it doesn't directly attack
the table starvation problem, and I think it could be a net loss of speed.
VACUUM is I/O bound, as such, just sending multiple vacuum commands at a
DB isn't going to make th
Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
> >After staring at my previous notes for autovac scheduling, it has become
> >clear that this basics of it is not really going to work as specified.
> >So here is a more realistic plan:
>
> [Snip Detailed Description]
>
> >How does this sound?
>
In an ideal world I think you want precisely one vacuum process running per
tablespace on the assumption that each tablespace represents a distinct
physical device.
The cases where we currently find ourselves wanting more are where small
tables are due for vacuuming more frequently than the time
Alvaro Herrera wrote:
After staring at my previous notes for autovac scheduling, it has become
clear that this basics of it is not really going to work as specified.
So here is a more realistic plan:
[Snip Detailed Description]
How does this sound?
On first blush, I'm not sure I like this a
On Fri, Feb 16, 2007 at 05:39:24PM -0300, Alvaro Herrera wrote:
> FWIW there's already a type called tinterval that stores (start,end). I
> don't think it's very much documented; maybe it can be extended or used
> as base for a new, more complete and robust type, indexable in a more
> natural way,
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> I'd suggest that the text is changed to something along the line of:
> "database system was interrupted while in recovery at ...
> If this has occurred more than once some data may be corrupted and
> you may need to restore from the last backup."
It
After staring at my previous notes for autovac scheduling, it has become
clear that this basics of it is not really going to work as specified.
So here is a more realistic plan:
First, we introduce an autovacuum_max_workers parameter, to limit the
total amount of workers that can be running at any
Jim C. Nasby wrote:
> My suggestion would be to focus on a period data type first and
> foremost, as that's something that could be readily used by a lot of
> folks. Of particular note, it's difficult to query tables that have
> start_time and end_time fields to define a period; it's easy to screw
My suggestion would be to focus on a period data type first and
foremost, as that's something that could be readily used by a lot of
folks. Of particular note, it's difficult to query tables that have
start_time and end_time fields to define a period; it's easy to screw up
the boundary conditions,
Hi
When postgres crashes during recovery, and is then restarted, it
says:
"database system was interrupted while in recovery at ...
This probably means that some data is corrupted and
you will have to use the last backup for recovery."
When I first read that message, I assumed that there are cas
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So it seems neither can_coerce_type() nor find_coercion_pathway() are
>> really particularly well thought out in terms of what they test or don't
>> test. I'm not very sure what a good refactoring would look like,
>> but I am sure that I
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Not here:
> Fixed.
Looks good, thanks.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
Tom Lane wrote:
> Not here:
Fixed.
> And this is in a build WITHOUT xml enabled --- why is this code being
> compiled at all?
The enablement pertains to libxml, which this code doesn't use.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadca
Tom Lane wrote:
So it seems neither can_coerce_type() nor find_coercion_pathway() are
really particularly well thought out in terms of what they test or don't
test. I'm not very sure what a good refactoring would look like,
but I am sure that I don't want all their call sites having to
individua
On 2/16/07, Zeugswetter Andreas ADI SD <[EMAIL PROTECTED]> wrote:
Oh sorry. Thanks for the clarification. Imho HEAP_UPDATE_ROOT should be
renamed for this meaning then (or what does ROOT mean here ?).
Maybe HEAP_UPDATE_CHAIN ?
Yes, you are right. There is some disconnect between what Simon h
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> In it I said that removing the 2-byte cases had no advantages but actually
>> since then I've thought of one. It makes the toaster code simpler since it
>> can
>> just set a bit in the four-byte header just as
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 16. Februar 2007 16:09 schrieb Tom Lane:
>> This "fix" doesn't fix anything.
> Sure, it fixes the compilation failures.
Not here:
gcc -O1 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-fno-strict-aliasing -g -I../../../../src/incl
Gregory Stark <[EMAIL PROTECTED]> writes:
> In it I said that removing the 2-byte cases had no advantages but actually
> since then I've thought of one. It makes the toaster code simpler since it can
> just set a bit in the four-byte header just as it does now. It doesn't have to
> worry about conv
> Just to avoid any confusion with the patch I sent out this
> week, we are setting HEAP_UPDATE_ROOT on all tuples which are
> HOT-updated.
>
> We set HEAP_ONLY_TUPLE for all tuples which does not have
> index reference. So may be combination of (HEAP_UPDATE_ROOT &
> ~HEAP_ONLY_TUPLE) can be
Seneca Cunningham wrote:
> Multiple systems are occasionally failing the timestamptz test at the
> check stage. From what I can tell, this is due to the newly added ISO
> week checks referring to TIMESTAMP_TBL used by the timestamp test
> instead of TIMESTAMPTZ_TBL. Both checks run at the same
On 2/16/07, Zeugswetter Andreas ADI SD <[EMAIL PROTECTED]> wrote:
> > As described, you've made
> > that problem worse because you're trying to say we don't know which
of
> > the chain entries is pointed at.
>
> There should be a flag, say HOT_CHAIN_ENTRY for the tuple the
it's called HEAP_UPD
> > As described, you've made
> > that problem worse because you're trying to say we don't know which
of
> > the chain entries is pointed at.
>
> There should be a flag, say HOT_CHAIN_ENTRY for the tuple the
it's called HEAP_UPDATE_ROOT
> index(es) point at. And this should be the preferred CT
On 2/16/07, Hannu Krosing <[EMAIL PROTECTED]> wrote:
Ühel kenal päeval, K, 2007-02-14 kell 10:41, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > OTOH, for same page HOT tuples, we have the command and trx ids stored
> > twice first as cmax,xmax of the old tuple and as cmin,xm
Am Freitag, 16. Februar 2007 16:09 schrieb Tom Lane:
> This "fix" doesn't fix anything.
Sure, it fixes the compilation failures.
> We have always in the past managed to
> avoid assuming that int64 actually is available; I don't intend to give
> the xml code a free pass to break that,
I don't in
I sent two emails last night, one to -patches and one to -hackers. Neither
seems to have come through. Has anyone else seen them? I sent this email once
already too and it hasn't come through. I'm resending it from a different
account now.
On -patches I posted an updated patch that was functional
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 16. Februar 2007 14:59 schrieb Alvaro Herrera:
>> UX:acomp: ERROR: "xml.c", line 2188: undefined symbol: INT64_MAX
>> UX:acomp: ERROR: "xml.c", line 2188: undefined symbol: INT64_MIN
>>
>> http://buildfarm.postgresql.org/cgi-bin/show_log.p
Multiple systems are occasionally failing the timestamptz test at the
check stage. From what I can tell, this is due to the newly added ISO
week checks referring to TIMESTAMP_TBL used by the timestamp test
instead of TIMESTAMPTZ_TBL. Both checks run at the same segment, so
the test fails if the
Am Freitag, 16. Februar 2007 14:59 schrieb Alvaro Herrera:
> UX:acomp: ERROR: "xml.c", line 2188: undefined symbol: INT64_MAX
> UX:acomp: ERROR: "xml.c", line 2188: undefined symbol: INT64_MIN
>
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=warthog&dt=2007-02-1
>6%2009:06:01
It needs a
Ühel kenal päeval, K, 2007-02-14 kell 10:41, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > OTOH, for same page HOT tuples, we have the command and trx ids stored
> > twice first as cmax,xmax of the old tuple and as cmin,xmin of the
> > updated tuple. One of these could probably
On Fri, Feb 16, 2007 at 02:09:41PM +0900, Yoshiyuki Asaba wrote:
> > > Does not compile on my MinGW - errors in the system headers (unistd.h,
> > > io.h) due to changing the argument format for chsize(). The change of
> > > off_t propagated into parts of the system headers, thus chaos was
> > > en
Gregory Stark wrote:
>
> I sent two emails last night, one to -patches and one to -hackers. Neither
> seems to have come through. Has anyone else seen them?
Not yet, but I got bounces from the server saying
451 - Server configuration problem
or something to that effect. Since my emails were ev
Am Freitag, 16. Februar 2007 08:46 schrieb Peter Eisentraut:
> Log Message:
> ---
> Functions for mapping table data and table schemas to XML (a.k.a. XML
> export)
Breaks various platforms. I'm on it.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Ühel kenal päeval, N, 2007-02-15 kell 10:49, kirjutas Heikki
Linnakangas:
> We already log tuple removals by normal vacuums. We can't use that wal
> entry as it is: if a dead tuple is in the middle of an update chain, it
> needs to be unlinked from the chain. But I don't see any particular
> pr
I sent two emails last night, one to -patches and one to -hackers. Neither
seems to have come through. Has anyone else seen them?
On -patches I posted an updated patch that was functionally a noop but changed
the macro api to SETVARSIZE(). It also replaced the VARATT_SIZE and
VARATT_DATA macros w
UX:acomp: ERROR: "xml.c", line 2188: undefined symbol: INT64_MAX
UX:acomp: ERROR: "xml.c", line 2188: undefined symbol: INT64_MIN
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=warthog&dt=2007-02-16%2009:06:01
--
Alvaro Herrerahttp://www.CommandPrompt.com
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Feb 08, 2007 at 01:54:13PM -0500, Tom Lane wrote:
>> I would be satisfied if the returned command tag were something else,
>> maybe "NO OPERATION".
> "TABLE blah DID NOT EXIST" might be less confusing...
You're confusing a command tag with a no
On 2/15/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> yikes!
> If you guys go through with forcing functions to attach to objects
> when they are created, it will break almost every project I've ever
> worked on :(. The schema/function combo fits into al
48 matches
Mail list logo
