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
-
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
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 posting/re
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
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
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Hey at least I noticed that InnoDB has one essential feature we don't:
>> SELECT ... IN SHARE MODE;
>>
>> 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 fo
Chris,
> Hey at least I noticed that InnoDB has one essential feature we don't:
>
> SELECT ... IN SHARE MODE;
>
> 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.
--
-Josh Berkus
__A
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 n
On Tue, 3 Feb 2004, Christopher Kings-Lynne wrote:
> > 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
> bac
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
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
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 upg
On Mon, 2 Feb 2004, Kevin Barnard wrote:
> 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
I must have missed this post when it was made earlier. Pardon the noise if
my suggestion has already been made.
Unlike MySQL (and possibly other database servers) PostgreSQL is faster when
inserting inside a transaction. Depending on the method in which you are
actually adding the records.
In my
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 a
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
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 imp
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
> head-
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, m
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
On Mon, 2004-02-02 at 13:43, 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
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, user
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
>
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 both? Did anyone make such tests?
Regards,
Tomasz My
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 wor
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 th
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 Da
Dnia 2004-02-02 15:46, Użytkownik 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 usele
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.
Rigmor Ukuhe
Finestmedia Ltd
---
Outgoing mail is certified Virus Free.
Checked by AVG anti
On Saturday 31 January 2004 04:35, Neil Conway wrote:
>
> This is called a "materialized view". PostgreSQL doesn't support them
> yet, but most people think it would be a Good Thing to have.
There is a project on gborg (called "mview" iirc) though I don't know how far
it's got - I think it's stil
30 matches
Mail list logo
