Hi all,
i have strange problem with performance in PostgreSQL (8.1.9). My problem
shortly:
I'm using postgreSQL via JDBC driver (postgresql-8.1-404.jdbc3.jar) and
asking the database for search on table with approximately 3 000 000
records.
I have created functional index table(lower(href)
2008/2/25, Pavel Rotek <[EMAIL PROTECTED]>:
> I have created functional index table(lower(href) varchar_pattern_ops)
> because of lower case "like" searching. When i ask the database directly
> from psql, it returns result in 0,5 ms, but when i put the same command via
> jdbc driver, it returns i
On Fri, 22 Feb 2008, Susan Russo wrote:
I'm wondering if anyone has had success doing a simultaneous
load of one Pg dump to two different servers? The load command
is actually run from two different workstations, but reading the
same pgdump-file.
Please don't cross-post.
I can't see any probl
On Fri, 22 Feb 2008, Kynn Jones wrote:
Hi. I'm trying to optimize...
(Q1) SELECT a1.word, a2.word
FROM T a1 JOIN T a2 USING ( zipk )
WHERE a1.type =
AND a2.type = ;
Okay, try this:
Create an index on T(type, zipk), and then CLUSTER on that index. That
will effecti
So, this email is directed much more towards Postgres Powers That Be. I
came across this problem a while ago, and I haven't checked whether it has
been improved.
On Mon, 25 Feb 2008, I wrote:
Hi. I'm trying to optimize...
(Q1) SELECT a1.word, a2.word
FROM T a1 JOIN T a2 USING ( zip
The thing to remember here is that prepared statements are only planned once
and strait queries are planned for each query.
When you give the query planner some concrete input like in your example
then it will happily use the index because it can check if the input starts
with % or _. If you use
On Feb 24, 2008, at 4:27 PM, Scott Marlowe wrote:
On Sun, Feb 24, 2008 at 6:05 PM, Sean Leach <[EMAIL PROTECTED]> wrote:
On Feb 24, 2008, at 4:03 PM, Scott Marlowe wrote:
What version pgsql is this? If it's pre 8.0 it might be worth
looking
into migrating for performance and maintenance
On Sun, 24 Feb 2008, Tom Lane wrote:
Sean Leach <[EMAIL PROTECTED]> writes:
I have a table, that in production, currently has a little over 3
million records in production. In development, the same table has
about 10 million records (we have cleaned production a few weeks
ago).
You mean the o
On Mon, Feb 25, 2008 at 8:45 AM, Matthew <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Feb 2008, Kynn Jones wrote:
> > Hi. I'm trying to optimize...
> >
> > (Q1) SELECT a1.word, a2.word
> > FROM T a1 JOIN T a2 USING ( zipk )
> >WHERE a1.type =
> > AND a2.type = ;
>
> Okay, t
On Mon, 25 Feb 2008, Kynn Jones wrote:
This is just GREAT!!! It fits the problem to a tee.
It makes the queries quick then?
Matthew
--
The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location...and i'm not
even too sure abou
Also, it might be worth enabling log_lock_waits to see if the slow
notifies are due to having to wait on some lock or other.
Turning on log_lock_waits shows that there is a lot of waiting for
locks on the pg_listener table ala:
process 22791 still waiting for ExclusiveLock on relation 2614 of
Joel Stevenson <[EMAIL PROTECTED]> writes:
>> Also, it might be worth enabling log_lock_waits to see if the slow
>> notifies are due to having to wait on some lock or other.
> Turning on log_lock_waits shows that there is a lot of waiting for
> locks on the pg_listener table ala:
Interesting. T
Also, it might be worth enabling log_lock_waits to see if the slow
notifies are due to having to wait on some lock or other.
Turning on log_lock_waits shows that there is a lot of waiting for
locks on the pg_listener table ala:
process 22791 still waiting for ExclusiveLock on relation 2614 of
At 1:13 PM -0500 2/25/08, Tom Lane wrote:
Joel Stevenson <[EMAIL PROTECTED]> writes:
Also, it might be worth enabling log_lock_waits to see if the slow
notifies are due to having to wait on some lock or other.
Turning on log_lock_waits shows that there is a lot of waiting for
locks on the
Joel Stevenson <[EMAIL PROTECTED]> writes:
> I turned on all autovacuum logging and cranked up the test script and
> have it fork 25 consumers each running 25 iterations. At that level
> on my machine I can get the lock waiting to exceed the 1s
> deadlock_timeout right away but the autovacuum a
At 2:57 PM -0500 2/25/08, Tom Lane wrote:
It's weird that the behavior is robust for you but I can't make it
happen at all. Would you show the output of pg_config, as well as
all your nondefault postgresql.conf settings?
pg_config:
BINDIR = /usr/local/pgsql/bin
DOCDIR = /usr/local/pgsql/doc
IN
I have a cascading delete trigger that is obviously using a seqscan.
(Explain analyze shows that trigger as taking over 1000s while all
other triggers are <1s. The value in test delete didn't even appear in
this child table, so an index scan would have been almost instant.)
If I do
DELETE FROM chi
Sean Leach wrote:
> On Feb 24, 2008, at 4:27 PM, Scott Marlowe wrote:
>
> >
> > Urg. Then I wonder how your indexes are bloating but your table is
> > not... you got autovac running? No weird lock issues? It's a side
> > issue right now since the table is showing as non-bloated (unless
> > you
On Feb 25, 2008, at 1:19 PM, Stephen Denne wrote:
So should I do a vacuum full and then hope this doesn't
happen again?
Or should I run a VACUUM FULL after each aggregation run?
If your usage pattern results in generating all of that unused space
in one transaction, and no further inserts
Sean Leach wrote
> On Feb 25, 2008, at 1:19 PM, Stephen Denne wrote:
> >
> >> So should I do a vacuum full and then hope this doesn't
> >> happen again?
> >> Or should I run a VACUUM FULL after each aggregation run?
> >
> > If your usage pattern results in generating all of that
> unused space
>
Sean Leach wrote
> On Feb 25, 2008, at 1:19 PM, Stephen Denne wrote:
> >
> >
> > Have you checked Scott Marlowe's note:
> >
> >>> unless you've got a long running transaction
> >
> > How come those 2 million dead rows are not removable yet? My guess
> > (based on a quick search of the mailing lis
On Feb 25, 2008, at 2:59 PM, Stephen Denne wrote:
Please know that I'm very new at advising PostgreSQL users how they
should tune their system...
I'd never have known it if you hadn't said anything
My understanding of your vacuum verbose output was that it was
pointing out that max_
Andrew Lazarus <[EMAIL PROTECTED]> writes:
> I have a cascading delete trigger that is obviously using a seqscan.
> (Explain analyze shows that trigger as taking over 1000s while all
> other triggers are <1s. The value in test delete didn't even appear in
> this child table, so an index scan would
23 matches
Mail list logo
