Joshua D. Drake <[EMAIL PROTECTED]> schrieb:
> salman Sheikh wrote:
>>
>>
>> Hi freinds,
>> i wanted to add my all tables once in MFC application,
>>
>> i have a databank,which has 11 tables and i want to add them all togather.
>>
>> After Adding all tables, it shows me always this errors by debu
Kevin Galligan wrote, On 29-10-08 23:35:
An example of a slow query is...
select count(*) from bigdatatable where age between 22 and 40 and state
= 'NY';
explain analyze returned the following...
Aggregate (cost=5179639.55..5179639.56 rows=1 width=0) (actual
time=389529.895..389529.897 ro
Hi..
I've this problem in installation...I installed the postgresql-8.3
version without the service...Then to initialize I gave the command
initdb -D path\ in the command prompt...It showed some notifications
and it finally said to start the database server I needed to enter the
command
C:\Progra
Gregory Stark wrote, On 01-11-08 14:02:
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
But sorry I still can't get WHY compression as a whole and data
integrity are mutually exclusive.
...
[snip performance theory]
Postgres *guarantees* that as long as everything else works correctly it
Grzegorz Jaśkiewicz wrote, On 30-10-08 12:13:
it should, every book on encryption says, that if you compress your data
before encryption - its better.
Those books also should mention that you should leave this subject to
experts and have numerous examples on systems that follow the book, but
I am attempting to move an unusually large legacy database from old DBF
files into a Postgres database. I've been able to clean up the DBF
tables, export them to CSV and convert that CSV into a SQL batch file.
My batch file contains 10 million INSERT queries to populate the
corresponding table
On Sun, Nov 02, 2008 at 02:13:34PM -0600, Milarsky, Jeremy F. wrote:
> I am attempting to move an unusually large legacy database from old DBF
> files into a Postgres database. I've been able to clean up the DBF
> tables, export them to CSV and convert that CSV into a SQL batch file.
At a wild g
On 02/11/2008 19:15, Shashank Mujumdar wrote:
> C:\Program Files\PostgreSQL\8.3\bin> postgres -D C:\path\to\pgsqldata
>
> when I entered the command I got the following notification..
>
> LOG: database system was shut down at 2008-11-02 18:17:13 IST
> LOG: database system is ready to accept co
/*--
Bienvenidos a:
PGDay 2008 Rio de la Plata
Organizado por la comunidad de PostgreSQL de Bs As (BaPUG)
Web: www.postgres-arg.org
-
On 02/11/2008 19:15, Shashank Mujumdar wrote:
> After this nothing happens..The command prompt does not appear..As if
> the cursor is waiting for some input or something like that..
> Please let me know if I missed something in installation process..What
> might be the problem ???
I meant to add
Hello everyone,
I am new to the forum and fairly new to databases (particularly PostgreSQL).
I have done some searching on the internet and can't really get a hold of an
answer to my question. So here it goes:
I am working on a Customer Purchasing-based project where I must use a
database with e
Joris Dobbelsteen wrote:
> Also I still have to see an compression algorithm that can sustain over
> (or even anything close to, for that matter) 100MB/s on todays COTS
> hardware. As TOAST provides compression, maybe that data can be
> transmitted in compressed manner (without recompression).
I
Brian714 wrote:
Hello everyone,
I am new to the forum and fairly new to databases (particularly PostgreSQL).
I have done some searching on the internet and can't really get a hold of an
answer to my question. So here it goes:
I am working on a Customer Purchasing-based project where I must use
Hi
Generally, I have avoided using VIEWS within application code and only
used them for client interfaces, the sole reason being the performance
of views against tables.
Changes to database over the past few years appear to have improved the
performance of views, but I am still not comfortab
On Sun, Nov 2, 2008 at 4:11 PM, Simon Windsor
<[EMAIL PROTECTED]> wrote:
> Hi
>
> Generally, I have avoided using VIEWS within application code and only used
> them for client interfaces, the sole reason being the performance of views
> against tables.
Have you confirmed this belief with tests? O
On Sun, Nov 02, 2008 at 02:30:45PM -0800, Brian714 wrote:
> I would like to convert the column that used to be
> "credit_card_number" from the Customers table and turn it into a "cc_id"
> which is an integer that references the column "id" from the table
> Creditcards.
[...]
> Does anyone know of a
>> Am I right to avoid to VIEWS within application code?
How one uses views is more a matter of taste and best practices, than
a matter of rules like this. Frankly, this "rule" sounds rather ill
conceived.
My feeling is that views can be difficult to maintain when they are
nested, but otherwise
On Mon, Nov 03, 2008 at 08:18:54AM +0900, Craig Ringer wrote:
> Joris Dobbelsteen wrote:
> > Also I still have to see an compression algorithm that can sustain over
> > (or even anything close to, for that matter) 100MB/s on todays COTS
> > hardware. As TOAST provides compression, maybe that data c
Sam Mason wrote:
On Mon, Nov 03, 2008 at 08:18:54AM +0900, Craig Ringer wrote:
Joris Dobbelsteen wrote:
Also I still have to see an compression algorithm that can sustain over
(or even anything close to, for that matter) 100MB/s on todays COTS
hardware. As TOAST provides compression, maybe that
Milarsky, Jeremy F. wrote:
I have, for the record, attempting to get all 10 million rows in with a
single COPY command. This method has not been successful, apparently due
to client encoding (despite executing several different "set
client_encoding" in each attempt).
This is probably something
Craig Ringer <[EMAIL PROTECTED]> writes:
> I get 19 Mbit/s from gzip (deflate) on my 2.4GHz Core 2 Duo laptop. With
> lzop (LZO) the machine achieves 45 Mbit/s. In both cases only a single
> core is used. With 7zip (LZMA) it only manages 3.1 Mb/s using BOTH cores
> together.
It'd be interesting to
Simon,
* Simon Windsor ([EMAIL PROTECTED]) wrote:
> Generally, I have avoided using VIEWS within application code and only
> used them for client interfaces, the sole reason being the performance
> of views against tables.
Views really shouldn't have a large impact on overall performance. In
Tom Lane wrote:
Wire protocol compression support in PostgreSQL would probably still be
extremely useful for Internet or WAN based clients, though,
Use an ssh tunnel ... get compression *and* encryption, which you surely
should want on a WAN link.
An ssh tunnel, while very useful, is only su
On Sun, Nov 2, 2008 at 6:39 PM, Stephen Frost <[EMAIL PROTECTED]> wrote:
> Simon,
>
>> * Higher overhead mapping to original tables and indexes
>
> This just plain isn't true in PG, at least, and I'd think most other
> sensible databases..
Note that, at least in older versions, MySQL completely
On Mon, Nov 03, 2008 at 10:01:31AM +0900, Craig Ringer wrote:
> Sam Mason wrote:
> >Your lzop numbers look *very* low; the paper suggests
> >compression going up to ~0.3GB/s on a 2GHz Opteron.
>
> Er ... ENOCOFFEE? . s/Mb(it)?/MB/g . And I'm normally *so* careful about
> Mb/MB etc; this was just
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> Note that, at least in older versions, MySQL completely materialized a
> temporary table from a view, then used that for the view. This is
> horribly inefficient, and results in a lot of people thinking views
> are slow. Not sure if this has been addr
We've been toying around with reworking our years old database schema and
replacing the old tables with updatable views into the new schema. The only
real problem we've had with it is that queries to one of our views seem to
be joining on unnecessary tables because the view does the join. We don'
On Sun, Nov 2, 2008 at 7:19 PM, Sam Mason <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 03, 2008 at 10:01:31AM +0900, Craig Ringer wrote:
>> So - it's potentially even worth compressing the wire protocol for use
>> on a 100 megabit LAN if a lightweight scheme like LZO can be used.
>
> The problem is tha
does anyone know if postgres support 'refresh' of applicable index(es) of a
materialized view on refresh?
Thanks,
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of Sende
On Sun, Nov 2, 2008 at 7:40 PM, Martin Gainty <[EMAIL PROTECTED]> wrote:
> does anyone know if postgres support 'refresh' of applicable index(es) of a
> materialized view on refresh?
Postgresql has no built in support for materialized views. If you
follow the excellent tutorial on how to make yo
Gday,
I'm currently converting an MS Access database to PostgreSQL (version 8.1 as it
is the vesion that ships with CentOS 5).
I'm having trouble with an INSERT statement attempting to insert an empty value
('') into a field with data type DATE. This produces the following error
message:
ERRO
Mike Hall wrote:
Gday,
I'm currently converting an MS Access database to PostgreSQL (version 8.1 as it
is the vesion that ships with CentOS 5).
I'm having trouble with an INSERT statement attempting to insert an empty value
('') into a field with data type DATE. This produces the following er
am Mon, dem 03.11.2008, um 16:03:33 +0930 mailte Mike Hall folgendes:
> Gday,
>
> I'm currently converting an MS Access database to PostgreSQL (version 8.1 as
> it is the vesion that ships with CentOS 5).
>
> I'm having trouble with an INSERT statement attempting to insert an empty
> value (''
33 matches
Mail list logo
