On Thu, 14 Jun 2007, Gregory Maxwell wrote:
Linux has some instrumentation that might be useful for this testing,
echo 1 > /proc/sys/vm/block_dump
That bit was developed for tracking down who was spinning the hard drive
up out of power saving mode, and I was under the impression that very
ro
On Thu, 14 Jun 2007, Tom Lane wrote:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
You're correct. But we can't defend users from all possible errors.
Other side, that we need somehow to help user to identify what fts
configuration was used to produce tsvector. For example, comment on
tsvector colu
On Thu, 14 Jun 2007, Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
First, why are we specifying the server locale here since it never
changes:
server's locale is used just for one purpose - to select what text search
configuration to use by default. Any text search functions can
Bruce Momjian <[EMAIL PROTECTED]> writes:
> First, why are we specifying the server locale here since it never
> changes:
It's poorly described. What it should really say is the language
that the text-to-be-searched is in. We can actually support multiple
languages here today, the restriction be
I am confused by the CREATE FULLTEXT CONFIGURATION command:
http://momjian.us/expire/fulltext/SGML/ref/create-fulltext-config.sgml
First, why are we specifying the server locale here since it never
changes:
LOCALE
localename
is the name of the locale. It shoul
I wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> 2 Snowball's compiling infrastructure doesn't support Windows target.
> Yeah. Another problem with using their original source code is that
> running the Snowball compiler during build would not work for
> cross-compiled builds of Postgres,
On 6/14/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Thu, 2007-06-14 at 16:39 +0900, ITAGAKI Takahiro wrote:
> Greg Smith <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 11 Jun 2007, ITAGAKI Takahiro wrote:
> > > If the kernel can treat sequential writes better than random writes, is
> > > it worth sor
On Thu, Jun 14, 2007 at 03:38:44PM -0400, Robert Wojciechowski wrote:
> I've been testing the new UUID functionality in 8.3dev and noticed that
> UUIDs are sorted using memcmp in their default in-memory layout, which
> is:
> struct uuid {
> uint32_ttime_low;
>
"Robert Wojciechowski" <[EMAIL PROTECTED]> writes:
> That was my thinking; that it would speed up (bulk) inserts causing
> fewer page splits.
Ah, I understand better now. hm. high data density would be good for reading.
But I think the case for inserting is actually quite mixed. If you have lots
"Robert Wojciechowski" <[EMAIL PROTECTED]> writes:
> When done that way, you're going to see a lot of index B-tree
> fragmentation with even DCE 1.1 (ISO/IEC 11578:1996) time based UUIDs,
> as described above. With random (version 4) or hashed based (version 3
> or 5) UUIDs there's nothing that c
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > I believe he means that with his modified comparison function, when
> > inserting a series of UUIDs with increasing time-fields, the index
keys
> > are always inserted to the rightmost page, which gives a more
tightly
> > packed index than scatte
> >> I've been testing the new UUID functionality in 8.3dev and noticed
that
> >> UUIDs are sorted using memcmp in their default in-memory layout,
> >> ...
> >> When done that way, you're going to see a lot of index B-tree
> >> fragmentation with even DCE 1.1 (ISO/IEC 11578:1996) time based
UUIDs,
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I believe he means that with his modified comparison function, when
> inserting a series of UUIDs with increasing time-fields, the index keys
> are always inserted to the rightmost page, which gives a more tightly
> packed index than scattered ins
Tom Lane wrote:
"Robert Wojciechowski" <[EMAIL PROTECTED]> writes:
I've been testing the new UUID functionality in 8.3dev and noticed that
UUIDs are sorted using memcmp in their default in-memory layout,
...
When done that way, you're going to see a lot of index B-tree
fragmentation with even DC
"Robert Wojciechowski" <[EMAIL PROTECTED]> writes:
> I've been testing the new UUID functionality in 8.3dev and noticed that
> UUIDs are sorted using memcmp in their default in-memory layout,
> ...
> When done that way, you're going to see a lot of index B-tree
> fragmentation with even DCE 1.1 (IS
It should be. Instances of ispell (and synonym, thesaurus) dictionaries are
different only in dict_initoption part, so it will be only one entry in
pg_ts_dict_template and several ones in pg_ts_dict.
No, I was thinking of still having just one pg_ts_dict catalog (no template)
but removing its d
Michael Paesold <[EMAIL PROTECTED]> writes:
> After reading the discussion and the introduction, here is what I think
> tsearch in core should at least accomplish in 8.3.
> ...
> - Stop words in tables, not in external files.
I realized that there's a pretty serious problem with doing that, whi
"Oleg Bartunov" <[EMAIL PROTECTED]> writes:
> On Thu, 14 Jun 2007, Gregory Stark wrote:
>
>> Am I correct to think of this like changing collations leaving your btree
>> index "corrupt"? In that case it probably won't cause any backend crash
>> either
>> but you will get incorrect results. For ex
I've been testing the new UUID functionality in 8.3dev and noticed that
UUIDs are sorted using memcmp in their default in-memory layout, which
is:
struct uuid {
uint32_ttime_low;
uint16_ttime_mid;
uint16_ttime_hi_and_version
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Teodor Sigaev <[EMAIL PROTECTED]> writes:
>>> The reason to save SQLish interface to dictionaries is a simplicity of
>>> configuration. Snowball's stemmers are useful as is, but ispell dictionary
>>> requires some configuration action
Bruce Momjian wrote:
I an attempt to communicate what full text search does, and what
features we are thinking of adding/removing, I have put up the
introduction in HTML:
http://momjian.us/expire/fulltext/HTML/fulltext-intro.html
Very good idea, Bruce!
After reading the discussion an
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> You're correct. But we can't defend users from all possible errors.
> Other side, that we need somehow to help user to identify what fts
> configuration was used to produce tsvector. For example, comment on
> tsvector column would be useful, but we don'
Am I correct to think of this like changing collations leaving your btree
index "corrupt"? In that case it probably won't cause any backend crash either
but you will get incorrect results. For example, returning different results
depending on whether the index or a full table scan is used.
Witho
But, there are reasons to allow users register new templates and in fact
we know people/projects with application-dependent dictionaries. How
they could dump/reload their dictionaries ?
The same way as pg_am does.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
On Thu, 14 Jun 2007, Gregory Stark wrote:
"Teodor Sigaev" <[EMAIL PROTECTED]> writes:
But they still need some more thought about permissions, because AFAICS
mucking with a configuration can invalidate some other user's data.
ouch. could mucking with a configuration create a corrupt index?
On Thu, 14 Jun 2007, Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
The reason to save SQLish interface to dictionaries is a simplicity of
configuration. Snowball's stemmers are useful as is, but ispell dictionary
requires some configuration action before using.
Yeah. I had been w
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
The reason to save SQLish interface to dictionaries is a simplicity of
configuration. Snowball's stemmers are useful as is, but ispell dictionary
requires some configuration action before using.
Yeah. I had been wondering about movi
"Teodor Sigaev" <[EMAIL PROTECTED]> writes:
>>> But they still need some more thought about permissions, because AFAICS
>>> mucking with a configuration can invalidate some other user's data.
>>
>> ouch. could mucking with a configuration create a corrupt index?
>
> Depending on what you mean 'cor
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> The reason to save SQLish interface to dictionaries is a simplicity of
> configuration. Snowball's stemmers are useful as is, but ispell dictionary
> requires some configuration action before using.
Yeah. I had been wondering about moving the dict_ini
But they still need some more thought about permissions, because AFAICS
mucking with a configuration can invalidate some other user's data.
ouch. could mucking with a configuration create a corrupt index?
Depending on what you mean 'corrupted'. It will not corrupted as non-readable
or cause b
can we hard-code into the backend, and just update for every major
release like we do for encodings?
Sorry, no one of them :(. We know projects which introduce new parser, new
dictionary. Config and map are changes very often.
--
Teodor Sigaev E-mail: [EMAIL
Well assuming we have any SQL-level support at all I think we should
strive to avoid these functions taking INTERNAL arguments.
That gets us down to just needing to worry about whether we like the
SQL representation of configurations. Which is still a nontrivial
issue, but at least it seems ma
I an attempt to communicate what full text search does, and what
features we are thinking of adding/removing, I have put up the
introduction in HTML:
http://momjian.us/expire/fulltext/HTML/fulltext-intro.html
The links to the other sections don't work yet.
--
On Thu, 2007-06-14 at 16:39 +0900, ITAGAKI Takahiro wrote:
> Greg Smith <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 11 Jun 2007, ITAGAKI Takahiro wrote:
> > > If the kernel can treat sequential writes better than random writes, is
> > > it worth sorting dirty buffers in block order per file at the s
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Well my argument has always been the "core" feature argument. Perhaps I
am missing some info here, but when I read what you wrote, I read that
Tsearch will now be "harder" to work with. Not easier. :(
Then you misread it. What I w
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Well my argument has always been the "core" feature argument. Perhaps I
> am missing some info here, but when I read what you wrote, I read that
> Tsearch will now be "harder" to work with. Not easier. :(
Then you misread it. What I was proposing
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
O.k. I am not trying to throw any cold water on this, but with the
limitations we are suggesting, does the patch gain us anything over just
leaving tsearch in contrib?
Well, if you want to take a hard-nosed approach, no form of the
Joshua D. Drake wrote:
> Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> >> Well assuming we have any SQL-level support at all I think we should
> >> strive to avoid these functions taking INTERNAL arguments.
>
> > That gets us down to just needing to worry about whether we like th
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> O.k. I am not trying to throw any cold water on this, but with the
> limitations we are suggesting, does the patch gain us anything over just
> leaving tsearch in contrib?
Well, if you want to take a hard-nosed approach, no form of the patch
would
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
Well assuming we have any SQL-level support at all I think we should
strive to avoid these functions taking INTERNAL arguments.
That gets us down to just needing to worry about whether we like the
SQL representation of configurations.
Gregory Stark <[EMAIL PROTECTED]> writes:
> Well assuming we have any SQL-level support at all I think we should
> strive to avoid these functions taking INTERNAL arguments.
I don't think I want to get into redesigning the patch at that level of
detail, at least not for 8.3. It seems like somethi
On Thu, 14 Jun 2007, ITAGAKI Takahiro wrote:
I think we need a discussion board for I/O performance issues. Can I use
Developers Wiki for this purpose? Since performance graphs and result
tables are important for the discussion, so it might be better than
mailing lists, that are text-based.
Alvaro Herrera wrote:
> ITAGAKI Takahiro wrote:
> > Hmm, how about canceling only the cases of DROP TABLE, TRUNCATE and CLUSTER.
> > We will obviously not need the table after the commands. Other commands,
> > VACUUM (FULL), ANALYZE, CREATE INDEX (CONCURRENTLY), REINDEX and LOCK TABLE
> > still co
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Sure, it can do that. I think it's easy enough to correct this problem;
> > see attached patch. Should this be backpatched? Earlier releases also
> > fall foul of this problem AFAICT.
>
> Yeah, because what made me think about it
ITAGAKI Takahiro wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > ITAGAKI Takahiro wrote:
> > > autovacuum killer triggered in CREATE/DROP/RENAME DATABASE commands.
> > > Can we extend the feature to several TABLE commands?
> >
> > Well, one problem with this is that currently SIGINT canc
ITAGAKI Takahiro wrote:
Greg Smith <[EMAIL PROTECTED]> wrote:
On Mon, 11 Jun 2007, ITAGAKI Takahiro wrote:
If the kernel can treat sequential writes better than random writes, is
it worth sorting dirty buffers in block order per file at the start of
checkpoints?
I wrote and tested the attach
On Thu, Jun 14, 2007 at 03:08:00PM +0200, Magnus Hagander wrote:
> On Thu, Jun 14, 2007 at 02:35:29PM +0200, Magnus Hagander wrote:
> > On Thu, Jun 14, 2007 at 02:28:26PM +0200, Joachim Wieland wrote:
> > >
> > >
> > > On Thu, Jun 14, 2007 at 08:17:05AM -0400, Andrew Dunstan wrote:
> > > > Maybe
On Thu, Jun 14, 2007 at 02:35:29PM +0200, Magnus Hagander wrote:
> On Thu, Jun 14, 2007 at 02:28:26PM +0200, Joachim Wieland wrote:
> >
> >
> > On Thu, Jun 14, 2007 at 08:17:05AM -0400, Andrew Dunstan wrote:
> > > Maybe it uses a different CVS or something. Who knows? Aren't our diffs
> > > supp
On Thu, Jun 14, 2007 at 02:28:26PM +0200, Joachim Wieland wrote:
>
>
> On Thu, Jun 14, 2007 at 08:17:05AM -0400, Andrew Dunstan wrote:
> > Maybe it uses a different CVS or something. Who knows? Aren't our diffs
> > supposed to be done ignoring whitespace?
>
> pg_init() in pg_regress_ecpg.c has:
On Thu, Jun 14, 2007 at 08:17:05AM -0400, Andrew Dunstan wrote:
> Maybe it uses a different CVS or something. Who knows? Aren't our diffs
> supposed to be done ignoring whitespace?
pg_init() in pg_regress_ecpg.c has:
/* no reason to set -w for ecpg checks, except for when on windows */
We have these GUC variables that define a fraction of something:
#autovacuum_vacuum_scale_factor = 0.2 # fraction of rel size before
# vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of rel size before
# a
Magnus Hagander wrote:
On Thu, Jun 14, 2007 at 07:47:58AM -0400, Andrew Dunstan wrote:
The ECPG regression tests appear to be broken on MinGW (see buildfarm
trout and vaquita). Please tell me that this isn't a line ending problem
like it appears on cursory inspection.
It certainly l
On Thu, Jun 14, 2007 at 07:47:58AM -0400, Andrew Dunstan wrote:
>
> The ECPG regression tests appear to be broken on MinGW (see buildfarm
> trout and vaquita). Please tell me that this isn't a line ending problem
> like it appears on cursory inspection.
It certainly looks like that, but yak is
The ECPG regression tests appear to be broken on MinGW (see buildfarm
trout and vaquita). Please tell me that this isn't a line ending problem
like it appears on cursory inspection.
cheers
andrew
---(end of broadcast)---
TIP 5: don't forget to
"ITAGAKI Takahiro" <[EMAIL PROTECTED]> writes:
> Exactly. I think we need a discussion board for I/O performance issues.
> Can I use Developers Wiki for this purpose? Since performance graphs and
> result tables are important for the discussion, so it might be better
> than mailing lists, that a
"PFC" <[EMAIL PROTECTED]> writes:
> Anyway, seq-scan on InnoDB is very slow because, as the btree grows (just
> like postgres indexes) pages are split and scanning the pages in btree order
> becomes a mess of seeks. So, seq scan in InnoDB is very very slow unless
> periodic OPTIMIZE TABLE is appli
"Tom Lane" <[EMAIL PROTECTED]> writes:
> You could remove the immediate source of this objection if you could
> redesign the APIs for the underlying support functions to be more
> type-safe. I'm not sure how feasible or useful that would be though.
> The bottom-line question here is whether deve
"Tom Lane" <[EMAIL PROTECTED]> writes:
>> Attached is a small patch which adds this conditionally on a guc that
>> pg_admin or other GUI tools could set, leaving it unchanged for users.
>
> That makes things *worse* not better, since now tools would have to
> deal with both possibilities.
I was t
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro wrote:
> > autovacuum killer triggered in CREATE/DROP/RENAME DATABASE commands.
> > Can we extend the feature to several TABLE commands?
>
> Well, one problem with this is that currently SIGINT cancels the whole
> autovacuum worker, not
Greg Smith <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Jun 2007, ITAGAKI Takahiro wrote:
> > If the kernel can treat sequential writes better than random writes, is
> > it worth sorting dirty buffers in block order per file at the start of
> > checkpoints?
I wrote and tested the attached sorted-wri
Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Here's results from a batch of test runs with LDC. This patch only
> spreads out the writes, fsyncs work as before.
I saw similar results in my tests. Spreading only writes are enough
for OLTP at least on Linux with middle-or-high-grade storage sy
61 matches
Mail list logo