Hello,
Started to work with big tables (like 300GB) and performance problems started
to appear. :(
To simplify things - table has an index on From an index on To columns. And
it also have several other not indexed columns. There are 10+ of different
values for From and the same for T
Hi,
my answer may be out of topic since you might be looking for a
postgres-only solution.. But just in case
What are you trying to achieve exactly ? Is there any way you could
re-work your algorithms to avoid selects and use a sequential scan
(consider your postgres data as one big file) to
> my answer may be out of topic since you might be looking for a
> postgres-only solution.. But just in case
I'd like to stay with SQL.
> What are you trying to achieve exactly ? Is there any way you could
> re-work your algorithms to avoid selects and use a sequential scan
> (consider you
On Dec 2, 2007 11:26 AM, Mindaugas <[EMAIL PROTECTED]> wrote:
> I execute simple query "select * from bigtable where From='something'".
> Query returns like 1000 rows and takes 5++ seconds to complete. As far as I
> understand the query is slow because:
Can you post an EXPLAIN ANALYZE? Which v
"Mindaugas" <[EMAIL PROTECTED]> writes:
> I execute simple query "select * from bigtable where From='something'".
> Query returns like 1000 rows and takes 5++ seconds to complete.
As you pointed out that's not terribly slow for 1000 random accesses. It
sounds like your drive has nearly 5ms
> What exactly is your goal? Do you need this query to respond in under a
> specific limit? What limit? Do you need to be able to execute many instances
> of this query in less than 5s * the number of executions? Or do you have more
> complex queries that you're really worried about?
I'd like t
On Nov 30, 2007 4:15 AM, Robert Treat <[EMAIL PROTECTED]> wrote:
> Never take advice from a guy who top posts... A friend of mine just went
> through an OTG course and had good things to say, and I've heard other speak
> well of it too, so I'd probably recommend them, but there are several
> optio
On 02.12.2007, at 06:30, Merlin Moncure wrote:
I've been dying to know if anyone has ever done PostgreSQL training at
'the big nerd ranch'.
There are a couple of reviews floating around the web:
http://www.linux.com/articles/48870
http://www.linuxjournal.com/article/7847
I was in the course
Robert Treat wrote:
On Wednesday 28 November 2007 11:20, Usama Munir Dar wrote:
EnterpriseDB (www.enterprisedb.com), ofcourse
lame :-P
Have you or anyone you know tried the training offerings? or you think
its lame because i top posted , which of course would be a very poor
c
Hi all,
I'm busy evaluating PostgreSQL and I'm having performance problems on one of
my servers. I have a very simple one table database, and the client using
Mono 1.2.5.1 is running a loop doing INSERTs on the table. Initially I
tested this on my development PC, an old P4 system with 2GB RAM and
On 02/12/2007, Beyers Cronje <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm busy evaluating PostgreSQL and I'm having performance problems on one of
> my servers. I have a very simple one table database, and the client using
> Mono 1.2.5.1 is running a loop doing INSERTs on the table. Initially I
> t
On Sun, 2 Dec 2007, Beyers Cronje wrote:
Initially I tested this on my development PC, an old P4 system with 2GB
RAM and 10,000 INSERTs took ~12 secs on average, which I was fairly
satisfied with. I then moved everything over to our test server, a new
Dell 1950 server with quad core Xeon proce
Mindaugas wrote:
And I cannot use some index organized table or table partitioned by From :)
because there are at least 2 similar indexes by which queries can be executed -
From and To.
This makes things a bit tough. One trick is to vertically partition the
table into two new tables
>
> Your development system is probably running inexpensive IDE disks that
> cache writes, while the test server is not caching. If you loop over
> single inserts, PostgreSQL's default configuration will do a physical
> commit to disk after every one of them, which limits performance to how
> fast
I'd like to get confirmation that I'm correctly understanding the
times given in EXPLAIN ANALYZE. Taking the example given in the Using
Explain section of the docs,
http://www.postgresql.org/docs/current/static/using-explain
EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 <
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> I'd like to get confirmation that I'm correctly understanding the
> times given in EXPLAIN ANALYZE.
> ...
> Is this correct?
Looks about right to me. Note that some of what you are calling
"executor overhead" might also be classed as "gettimeofda
On Dec 2, 2007, at 19:56 , Tom Lane wrote:
IOW the actual time to get in and out of a node is going to be a
shade more
than is reported.
Thanks, Tom. Should be close enough for jazz.
When I was first going over the Using Explain section, I stumbled a
bit on the startup time/total time/lo
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> I took startup time to be the time to return the first row *of the
> first loop*. But it's actually the average startup time to return the
> first row *in each loop*, right?
Correct, just as the total time and tuples returned are averages over a
18 matches
Mail list logo
