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
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-writes
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 just the
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 thinking
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 developing
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 applied.
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 are
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
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
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
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
#
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 */
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 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
supposed to be
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 it uses a
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
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 cancels the whole
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 was a
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 conflict
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.
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 something
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.
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 gain
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 the
SQL
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 [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 was
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 was
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 start of
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.
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
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
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
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
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 'corrupted'. It
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
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
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?
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]
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.
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't
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
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 before using.
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_t
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 example,
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, which
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
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 (ISO/IEC
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 DCE
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 inserts
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,
This claim
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
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 can be
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
of
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;
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 sorting dirty
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, at
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:
varlistentry
termliteralLOCALE/literal/term
listitem
para
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 being
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
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
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
61 matches
Mail list logo
