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?
Ar
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 alr
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 regards
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 show(113
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 us
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, us
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 wro
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 c
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 c
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 -
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 re
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 verifie
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 sort
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.
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 mult
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 ba
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 ar
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
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.
> >>
>
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.
Exi
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
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, Clodoald
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 o
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 Ja
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 curren
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 withou
36 matches
Mail list logo
