Am Donnerstag, den 11.08.2005, 00:40 -0400 schrieb Mark Cotner:
Here's a trigger I wrote to perform essentially the same purpose. The nice
thing about this is it keeps the number up to date for you, but you do incur
slight overhead.
...
CREATE TRIGGER del_rowcount_tr BEFORE DELETE ON test
Am Donnerstag, den 11.08.2005, 20:36 +1000 schrieb Gavin Sherry:
On Thu, 11 Aug 2005, Tino Wildenhain wrote:
Am Donnerstag, den 11.08.2005, 00:40 -0400 schrieb Mark Cotner:
Here's a trigger I wrote to perform essentially the same purpose. The
nice
thing about this is it keeps
Am Donnerstag, den 11.08.2005, 14:08 +0200 schrieb PFC:
You could lock the count table to prevent the problem
where 2 competing transactions do an insert, read the
start value and add 1 to it and then write the result
- which is n+1 rather then n+2 - so you are off by one.
Think of the
Sebastian Hennebrueder schrieb:
Hello,
I would like to test the performance of my Java/PostgreSQL applications
especially when making full text searches.
For this I am looking for a database with 50 to 300 MB having text fields.
e.g. A table with books with fields holding a comment, table of
Am Donnerstag, den 01.12.2005, 10:07 -0800 schrieb Gavin M. Roy:
Hi Michael,
I'm a fan of ReiserFS, and I can be wrong, but I believe using a
journaling filesystem for the PgSQL database could be slowing things
down.
Have a 200G+ database, someone pulling the power plug
or a regular
Jenny schrieb:
I'm running PostgreSQL 8.0.3 on i686-pc-linux-gnu (Fedora Core 2). I've been
dealing with Psql for over than 2 years now, but I've never had this case
before.
I have a table that has about 20 rows in it.
Table public.s_apotik
Column | Type
Joost Kraaijeveld schrieb:
On Tue, 2005-12-06 at 10:52 +0100, Csaba Nagy wrote:
Joost,
Why do you use an offset here ? I guess you're traversing the table
somehow, in this case it would be better to remember the last zipcode +
housenumber and put an additional condition to get the next bigger
Joost Kraaijeveld schrieb:
Hi Tino,
..
Cursor would work too but you would need to have a persistent connection.
I just tried it: a cursor is not faster (what does not surprise me at
all, as the amount of work looks the same to me)
Actually no, if you scroll forward, you just ask the
Joost Kraaijeveld schrieb:
On Tue, 2005-12-06 at 12:36 +0100, Tino Wildenhain wrote:
I just tried it: a cursor is not faster (what does not surprise me at
all, as the amount of work looks the same to me)
Actually no, if you scroll forward, you just ask the database for the
next rows
Alessandro Baretta schrieb:
[EMAIL PROTECTED] wrote:
...
It looks like this is the only possible solution at present--and in the
future, too--but it has a tremendouse performance impact on queries
returning thousands of rows.
Well actually one of the better solutions would be persistent
Javier Somoza schrieb:
Hi all
Is it secure to disable fsync havin battery-backed disk cache?
Thx
No. fsync moves the data from OS memory cache to disk-adaptor
cache which is required to benefit from battery backup.
If this data is written to the
Thomas Vatter schrieb:
is there a possibility for creating views or temp tables in memory to
avoid disk io when user makes select operations?
No need. The data will be available in OS and database caches if
they are really required often. If not, tune up the caches and
do a regular pre select.
Thomas Vatter schrieb:
Tino Wildenhain wrote:
Thomas Vatter schrieb:
is there a possibility for creating views or temp tables in memory to
avoid disk io when user makes select operations?
No need. The data will be available in OS and database caches if
they are really required often
Thomas Vatter schrieb:
Tino Wildenhain wrote:
...
Well you will need the equally 40 seconds to fill your hypothetical
in memory table. (even a bit more due to the creation of a
datastructure).
So you can do the aproaches of semi materialized views (that are in fact
writing into a shadow
a
kill session is a bad idea?
You are sure you read:
http://www.postgresql.org/docs/8.1/interactive/protocol-flow.html#AEN60635
?
Regards
Tino Wildenhain
---(end of broadcast)---
TIP 6: explain analyze is your friend
Craig A. James schrieb:
...
In our case (for a variety of reasons, but this one is critical), we
actually can't use Postgres indexing at all -- we wrote an entirely
separate indexing system for our data, one that has the following
properties:
1. It can give out pages of information (i.e.
Craig A. James schrieb:
Tino Wildenhain wrote:
Craig A. James schrieb:
...
In our case (for a variety of reasons, but this one is critical), we
actually can't use Postgres indexing at all -- we wrote an entirely
separate indexing system for our data...
...There is no need to store
Michael Stone schrieb:
On Thu, Mar 22, 2007 at 02:24:39PM -0400, Merlin Moncure wrote:
Tino was saying that rather that build a complete indexing storage
management solution that lives outside the database, it is better to
do intelligent session management so that you get the simplicity if a
Craig A. James schrieb:
Tino Wildenhain wrote:
You guys can correct me if I'm wrong, but the key feature that's
missing from Postgres's flexible indexing is the ability to maintain
state across queries. Something like this:
select a, b, my_index_state() from foo where ...
offset 100
Michael Stone schrieb:
On Thu, Mar 22, 2007 at 06:27:32PM +0100, Tino Wildenhain wrote:
Craig A. James schrieb:
You guys can correct me if I'm wrong, but the key feature that's
missing from Postgres's flexible indexing is the ability to maintain
state across queries. Something like
Michael Stone schrieb:
On Fri, Mar 23, 2007 at 01:01:02PM +0100, Tino Wildenhain wrote:
This discussion is a bit theoretical until we see the actual problem
and the proposed solution here.
It's good to see you back off a bit from your previous stance of
assuming that someone doesn't know
Magnus Hagander schrieb:
I'd consider having a small daemon LISTENing for NOTIFYs that you send by
triggers whenever the table has changed. That'll make sure it only dumps if
something actually changed. And you can also implement some ratelimiting if
needed.
Do you really think such a
Mohamed Ali JBELI wrote:
Hi members
I am looking for an example of a web application (WAR) which executea a
Postgres actions. This aims to test the performance of Postgres in Web
mode.
I shall be grateful if someone gives me a link where I can find a WAR file.
A WAR file? Postgres is
Hi,
Matthew wrote:
On Tue, 11 Mar 2008, Bill Moran wrote:
In response to Robins Tharakan [EMAIL PROTECTED]:
Sorry, if I am missing something here, but shouldn't something like this
allow us to get a (fast) accurate count ?
SELECT COUNT(*) from table WHERE indexed_field IS NULL
+
SELECT
Justin wrote:
OK i'm showing my ignorance of linux. On Ubuntu i can't seem to figure
out if XFS file system is installed, if not installed getting it
installed.
Hm? Installed/not installed? You can select that when you are preparing
your partitions. If you run the automated partitioner
Adonias Malosso wrote:
Hi All,
I´d like to know what´s the best practice to LOAD a 70 milion rows, 101
columns table
from ORACLE to PGSQL.
The current approach is to dump the data in CSV and than COPY it to
Postgresql.
Uhm. 101 columns you say? Sounds interesting. There are dataloaders
Hi all the ignorers, ;)
Greg Smith wrote:
On Thu, 1 May 2008, D'Arcy J.M. Cain wrote:
Whenever I see one of those I simply blackhole the server sending them.
Ah, the ever popular vigilante spam method. What if the message is
coming from, say, gmail.com, and it's getting routed so that
Hi,
Luke Lonergan wrote:
BTW – we’ve removed HINT bit checking in Greenplum DB and improved the
visibility caching which was enough to provide performance at the same
level as with the HINT bit optimization, but avoids this whole “write
the data, write it to the log also, then write it again
Hi,
dforum wrote:
Hello every body,
I just discover a big not only big huge difference between NOW() and
CURRENT_DATE.
Did you already know about it and do you know why ?
DELETE FROM blacklist where bl_date (NOW() - interval '2 DAY');
on 6 000 000 of records
699 ms
DELETE FROM blacklist
29 matches
Mail list logo
