Dnia 2004-02-02 15:46, Uytkownik Rigmor Ukuhe napisa:
Hi,
I have many indexes somehow overlaping like:
... btree (STATUS, VISIBLE, NP_ID);
... btree (STATUS, VISIBLE);
is perfomance gained by more exact index worth overhead with managing
indexes.
The second (2 columns) index is useless - it's
Folks,
I've had requests from a couple of businesses to see results of infomal MySQL
+InnoDB vs. PostgreSQL tests.I know that we don't have the setup to do
full formal benchmarking, but surely someone in our community has gone
head-to-head on your own application?
--
-Josh Berkus
Aglio
Folks,
Is anyone on this list using PostgreSQL on a mini or mainframe platform? If
so, drop me a line. Thanks!
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 2: you can get off all lists at once with
On Mon, 2 Feb 2004, Tomasz Myrta wrote:
Dnia 2004-02-02 15:46, U?ytkownik Rigmor Ukuhe napisa3:
Hi,
I have many indexes somehow overlaping like:
... btree (STATUS, VISIBLE, NP_ID);
... btree (STATUS, VISIBLE);
is perfomance gained by more exact index worth overhead with managing
Dnia 2004-02-02 19:30, Uytkownik scott.marlowe napisa:
Not entirely, since it only has to sort two columns, it will be smaller,
and will therefore be somewhat faster.
Can you say something more about it? Will it be enough faster to keep
them both? Did anyone make such tests?
Regards,
Tomasz
On Mon, 2 Feb 2004, Tomasz Myrta wrote:
Dnia 2004-02-02 19:30, U¿ytkownik scott.marlowe napisa³:
Not entirely, since it only has to sort two columns, it will be smaller,
and will therefore be somewhat faster.
Can you say something more about it? Will it be enough faster to keep
them
I am running a Dual Xeon hyperthreaded server with 4GB RAM RAID-5. The only
thing running on the server is Postgres running under Fedora. I have a 700
connection limit.
The DB is setup as a backend for a very high volume website. Most of the queries
are simple, such as logging accesses,
On Mon, 2004-02-02 at 13:43, Tomasz Myrta wrote:
Dnia 2004-02-02 19:30, Uytkownik scott.marlowe napisa:
Not entirely, since it only has to sort two columns, it will be smaller,
and will therefore be somewhat faster.
Can you say something more about it? Will it be enough faster to keep
Quick Question,
The full query listed in pg_stat_activity is getting truncated. Does
anyone know how I can see the full query in progress?
--
Orion Henry [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
I am new here. I have a question related to this in some way.
Our web site needs to upload a large volume of data into Postgres at a
time. The performance deterioates as number of rows becomes larger.
When it reaches 2500 rows, it never come back to GUI. Since the tests
were run through GUI,
On Mon, 2004-02-02 at 12:21, Josh Berkus wrote:
Folks,
I've had requests from a couple of businesses to see results of infomal MySQL
+InnoDB vs. PostgreSQL tests.I know that we don't have the setup to do
full formal benchmarking, but surely someone in our community has gone
Josh,
I evaluated MySQL + InnoDB briefly for a project, once. I didn't get
very far because of some severe limitations in MySQL.
I had to import all of the data from an existing database (MS SQL).
One of the tables was about 8 million rows, 10 fields, and had 5
indexes. I found it quite
On Mon, 2 Feb 2004, Qing Zhao wrote:
I am new here. I have a question related to this in some way.
Our web site needs to upload a large volume of data into Postgres at a
time. The performance deterioates as number of rows becomes larger.
When it reaches 2500 rows, it never come back to
On Monday 02 February 2004 19:39, Qing Zhao wrote:
I am new here. I have a question related to this in some way.
Hmm - no real connection I can see - might have been better to start a new
thread rather than replying to this one. Also, it is usually considered best
practice not to quote large
On 2 Feb 2004 at 13:58, scott.marlowe wrote:
what do you mean at 2 GB? Is that how much is in kernel cache plus
buffer, plus used, plus etc??? Could you give us the top of top output to
make sure? If most of that is kernel cache, then that's fine.
2GB was total system memory. We
On Mon, 2 Feb 2004, Kevin Barnard wrote:
On 2 Feb 2004 at 13:58, scott.marlowe wrote:
what do you mean at 2 GB? Is that how much is in kernel cache plus
buffer, plus used, plus etc??? Could you give us the top of top output to
make sure? If most of that is kernel cache, then that's
One more thing that annoyed me. If you started a process, such as a
large DDL operation, or heaven forbid, a cartesian join (what? I never
do that!).
I believe InnoDB also has O(n) rollback time. eg. if you are rolling
back 100 million row changes, it takes a long, long time. In PostgreSQL
Seriously, I am tired of this kind of question. You gotta get bold
enough to stand up in a meeting like that, say guy's, you can ask me
how this compares to Oracle ... but if you're seriously asking me how
this compares to MySQL, call me again when you've done your homework.
Hey at least I
Um, wrong. We don't lock rows for SELECT.
No, but Chris is correct that we could do with having some kind of
shared lock facility at the row level.
Out of interest, what is it about this particular task that's so hard?
(Not that I could code it myself). But surely you can use the same sort
of
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
No, but Chris is correct that we could do with having some kind of
shared lock facility at the row level.
Out of interest, what is it about this particular task that's so hard?
Keeping track of multiple lockers in a fixed amount of disk
Out of interest, what is it about this particular task that's so hard?
Keeping track of multiple lockers in a fixed amount of disk space.
Why not look at how InnoDB does it? Or is that not applicable?
---(end of broadcast)---
TIP 3: if
Chris,
Which does a shared lock on a row as opposed to a write lock, hence
avoiding nasty foreign key deadlocks...
Um, wrong. We don't lock rows for SELECT.
Unless you meant something else? Am I not following you?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
Um, wrong. We don't lock rows for SELECT.
Unless you meant something else? Am I not following you?
I mean row level shared read lock. eg. a lock that says, you can read
but you cannot delete.
It's what postgres needs to alleviate its foreign key trigger deadlock
problems.
Chris
23 matches
Mail list logo
