On Fri, 2008-01-18 at 19:58 -0500, Tom Lane wrote:
In any case, 125 different zeroed pages is pretty hard to explain
by such a mechanism (especially if they were scattered rather than
in contiguous clumps).
Can you show us the messages, so we can understand the distribution of
the pages?
Are
On Friday 18 January 2008 18:04, Erik Jones wrote:
For our primary, er, main, onsite standby server that's also what we
do. But, this was a co-location to co-location transfer so there was
no NFS mount, it was a direct rsync to the server at the other co-
location. For WAL files, I've
Does it make any sense to CLUSTER by a GIST index to move tuples with
similar lexems physically closer together on disc, drop it and use GIN
for the actual queries?
My queries are bound by HDD seek speed currently, might the above help
me or can it even be counterproductive?
--
Best
Hi All,
I'm having trouble with turning off notices. Within psql I use \set VERBOSITY
terse, which is fine. However, using psql -c I am having trouble. It seems I
should be able to use psql -qc 'mycommand' but I am still getting notices
output, e.g.
psql -d combilex -qc 'SELECT * FROM
On Sat, 19 Jan 2008, Hannes Dorbath wrote:
Does it make any sense to CLUSTER by a GIST index to move tuples with similar
lexems physically closer together on disc, drop it and use GIN for the actual
queries?
My queries are bound by HDD seek speed currently, might the above help me or
can it
Oleg Bartunov wrote:
what do you want to speed up ? Search is very fast, see explain analyze.
The problem usually in the access to documents found to calculate
rank, headlines. If GIN returns N documents, then you need to read
all of them to calculate rank and here you get slowdown.
I don't
Hello
try:
echo '\set VERBOSITY terse\\SELECT * FROM show(1135311);' | psql -d combilex -q
Regards
Pavel Stehule
On 19/01/2008, Sue Fitt [EMAIL PROTECTED] wrote:
Hi All,
I'm having trouble with turning off notices. Within psql I use \set
VERBOSITY terse, which is fine. However, using
Thanks, this is a help - it has turned off the CONTEXT part, but the NOTICE
is still there.
Just looked at the same query inside psql for comparison, with '\set
VERBOSITY terse', but actually I see that here I am getting both NOTICE and
CONTEXT. Not sure what's going on here...
Anyway, it's
On Sat, 19 Jan 2008, Sue Fitt wrote:
Hi All,
I'm having trouble with turning off notices. Within psql I use \set
VERBOSITY terse, which is fine. However, using psql -c I am having
trouble. It seems I should be able to use psql -qc 'mycommand' but I am
still getting notices output, e.g.
Simon Riggs [EMAIL PROTECTED] writes:
The page numbers are identical between both systems, so use the
contrib/pageinspect get_raw_page() function to record the contents on
both systems before they diverge too much. (BTW, the final commit of
those tools seems to have removed the docs I wrote
On Sat, 2008-01-19 at 11:51 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The page numbers are identical between both systems, so use the
contrib/pageinspect get_raw_page() function to record the contents on
both systems before they diverge too much. (BTW, the final commit of
Thanks, a combination of the two answers solves it:
echo 'set client_min_messages TO WARNING; SELECT * FROM show(1135311);' |
psql -d combilex
Notices and their context now gone. Not sure why I had to use ';' rather
than '\\' to join the two statements, but it's working so I'm happy.
Sue
On Jan 19, 2008, at 2:26 AM, Simon Riggs wrote:
On Fri, 2008-01-18 at 19:58 -0500, Tom Lane wrote:
In any case, 125 different zeroed pages is pretty hard to explain
by such a mechanism (especially if they were scattered rather than
in contiguous clumps).
Can you show us the messages, so we
Erik Jones [EMAIL PROTECTED] writes:
On Jan 19, 2008, at 2:26 AM, Simon Riggs wrote:
Can you show us the messages, so we can understand the distribution of
the pages?
All of the warnings are below. For tables that had multiple warnings
they seem to be for consecutive pages.
Hmm --- that
Is there a place that gives examples of all the kind of queries
postgresql support?
Sometimes I think if there is a way to obtain a result in just one
statement without writing a function and it would be nice to have a
panoramic of all the strategies I could try for single statements.
The SQL
On Sat, 2008-01-19 at 11:28 -0600, Erik Jones wrote:
If the page_inspect module would work with 8.2 I wouldn't have a
problem building and using it, I already do that with pg_standby.
But, with three days of traffic on these table in the production
server and, having already verified
On 19/01/2008 18:22, Ivan Sergio Borgonovo wrote:
Is there a place that gives examples of all the kind of queries
postgresql support?
This may not be what you're looking for, but I've found O'Reilly's SQL
Cookbook (ISBN 0-596-00976-3) incredibly useful: it gives sample
solutions to all sorts
On Sat, 2008-01-19 at 11:28 -0600, Erik Jones wrote:
All of the warnings are below. For tables that had multiple warnings
they seem to be for consecutive pages. All of these tables were
seeing some pretty decent write traffic during the base backup which
took place Tuesday night. The
On Sat, 2008-01-19 at 12:56 -0500, Tom Lane wrote:
Erik Jones [EMAIL PROTECTED] writes:
On Jan 19, 2008, at 2:26 AM, Simon Riggs wrote:
Can you show us the messages, so we can understand the distribution of
the pages?
All of the warnings are below. For tables that had multiple warnings
On Jan 19, 2008, at 12:22 PM, Ivan Sergio Borgonovo wrote:
Is there a place that gives examples of all the kind of queries
postgresql support?
Sometimes I think if there is a way to obtain a result in just one
statement without writing a function and it would be nice to have a
panoramic of all
On Jan 19, 2008, at 1:24 PM, Simon Riggs wrote:
So we definitely have missing data. I think the multi-phase rsync is
definitely suspect and should be avoided until we get to the bottom of
this.
By this, do you mean the way we ran the rsync multiple times before
performing the actual base
On Fri, Jan 18, 2008 at 09:27:08PM +, Gordan Bobic wrote:
Andrew Sullivan wrote:
On Fri, Jan 18, 2008 at 04:09:45PM +, [EMAIL PROTECTED] wrote:
That's just it - I don't think any user-land libraries would
actually be required. One of supposed big advantages of MySQL is
it's
David Fetter wrote:
That's just it - I don't think any user-land libraries would
actually be required. One of supposed big advantages of MySQL is
it's straightforward replication support. It's quite painful to
see PostgreSQL suffer purely for the sake of lack of marketting in
this department.
Luca Arzeni [EMAIL PROTECTED] writes:
Is there any way to consider blanks meaningfull AND sort properly locale
specific vowels ?
This isn't a Postgres question, it's a locale question. (If you try,
you'll find that sort(1) sorts the same as we do in any given locale.)
I imagine you could
Gregory Youngblood wrote:
On Sat, 2008-01-19 at 23:46 +, Gordan Bobic wrote:
David Fetter wrote:
In that case, use one of the existing solutions. They're all way
easier than re-inventing the wheel.
Existing solutions can't handle multiple masters. MySQL can do it at
least in a ring
On Jan 15, 2008 6:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Luca Arzeni [EMAIL PROTECTED] writes:
That is: the sort order in postgres 8.1.9 seems to ignore the blank.
This is expected behavior in most non-C locales.
Try initdb --locale=C.
On Jan 19, 2008 5:46 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
David Fetter wrote:
That's just it - I don't think any user-land libraries would
actually be required. One of supposed big advantages of MySQL is
it's straightforward replication support. It's quite painful to
see PostgreSQL
On Jan 19, 2008 6:14 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
Gregory Youngblood wrote:
On Sat, 2008-01-19 at 23:46 +, Gordan Bobic wrote:
David Fetter wrote:
In that case, use one of the existing solutions. They're all way
easier than re-inventing the wheel.
Existing
Scott Marlowe wrote:
On Jan 19, 2008 6:14 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
Gregory Youngblood wrote:
On Sat, 2008-01-19 at 23:46 +, Gordan Bobic wrote:
David Fetter wrote:
In that case, use one of the existing solutions. They're all way
easier than re-inventing the wheel.
On Sun, 20 Jan 2008 00:34:11 + Gordan Bobic wrote:
Scott Marlowe wrote:
On Jan 19, 2008 6:14 PM, Gordan Bobic [EMAIL PROTECTED] wrote:
Oh, and there's this too:
Cybertec sync-multi-master
http://www.postgresql.org/about/news.752
http://www.postgresql.org/about/news.752
The
Clodoaldo [EMAIL PROTECTED] writes:
2008/1/16, Tom Lane [EMAIL PROTECTED]:
I don't know of any reason to think that insertion is slower in 8.3
than it was in 8.2, and no one else has reported anything of the sort.
The old server reproduces the behavior of the new one.
Okay, Clodoaldo kindly
Tom Lane wrote:
Clodoaldo [EMAIL PROTECTED] writes:
2008/1/16, Tom Lane [EMAIL PROTECTED]:
I don't know of any reason to think that insertion is slower in 8.3
than it was in 8.2, and no one else has reported anything of the sort.
The old server reproduces the behavior of
Hello,
you have to use correct localses for your encoding and country:
for czech and utf8 is
cs_CZ.UTF8 ..
for latin2 is
cs_CZ.latin2 etc
czech sorting has more exception and it works
caa
čaa
daa
cha ... it is well for czech
iaa
On 20/01/2008, Luca Arzeni [EMAIL PROTECTED] wrote:
On Jan
I'm a fan of unsecured languages in the database.
Obviously they should only be used by people who understand the difference.
I wouldn't want python locked down.
That would prevent so many different external functions that can now be
integrated into the database.
Among other things that I
Is there a reason why the conference is on a weekend?
There's no way I can make it on a weekend.
Sim
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Registration for PostgreSQL Conference: East is now open. For those who
haven't seen the emails, the conference is
I've found that multiple simple statements often work faster then convoluted
single statements.
Ivan Sergio Borgonovo wrote:
Is there a place that gives examples of all the kind of queries
postgresql support?
Sometimes I think if there is a way to obtain a result in just one
statement
36 matches
Mail list logo
