Jeff Davis wrote:
On Fri, 2011-07-08 at 23:39 -0700, Darren Duncan wrote:
What if you used the context of the calling code and resolve in favor of
whatever match is closest to it? The problem is related to general-purpose
programming languages.
Basically start looking in the lexical context
Hi,
On Sat, Jul 9, 2011 at 6:53 PM, Scott Marlowe wrote:
> On Sat, Jul 9, 2011 at 10:19 AM, Alexander Farber
> wrote:
>>
>> 1) 2 machines with i7-920 Quad-Core
>> 8 GB RAM, 2 x 750 GB SATA-II HDD
>> (Software-RAID 1)
>>
>> 2) 1 machine i7-980X Hexa-Core
>> 24 GB RAM, 1 x 1,5 TB SATA II
>
On Sat, Jul 9, 2011 at 10:19 AM, Alexander Farber
wrote:
> Hello,
>
> I'm running a CentOS 5.6 / 64 bit Linux
> with PostgreSQL 8.4.8 and Drupal 7.4
> on a 4GB quad-CPU machine.
>
> In Autumn I can change my hoster
> and for EUR 100 can either take
>
> 1) 2 machines with i7-920 Quad-Core
> 8 GB
On 07/09/2011 12:56 PM, Jonathan Camilleri wrote:
/Notes for Windows users/
http://www.postgresql.org/docs/9.0/static/app-psql.html
Hello,
I'm running a CentOS 5.6 / 64 bit Linux
with PostgreSQL 8.4.8 and Drupal 7.4
on a 4GB quad-CPU machine.
In Autumn I can change my hoster
and for EUR 100 can either take
1) 2 machines with i7-920 Quad-Core
8 GB RAM, 2 x 750 GB SATA-II HDD
(Software-RAID 1)
or
2) 1 machine i7-980X H
Hello all,
I am having a little trouble with a hot standby configuration on Windows,
and I was hoping I could find an answer here.
Everything works fine (both machines run just fine, and the hot standby
works like a charm), except for one problem. The pg_archivecleanup refuses
to run; it seems li
1. Upon logging to *SQL shell* the following is being displayed:
*Server [localhost]:*
*Database [postgres]:*
*Port [5432]:*
*Username [postgres]:*
*psql (9.0.4)*
*WARNING: Console code page (437) differs from Windows code page (1252)*
* 8-bit characters might not work correctly. See psql r
On Fri, 2011-07-08 at 23:39 -0700, Darren Duncan wrote:
> What if you used the context of the calling code and resolve in favor of
> whatever match is closest to it? The problem is related to general-purpose
> programming languages.
>
> Basically start looking in the lexical context for an "x"
>
> create table invoice_attachment (
> check (file_class = 1),
> foreign key(ref_key) references invoice(id),
> ) inherits (file_attachment);
>
> create table order_attachment (
> check(file_class = 2),
> foreign key (ref_key) references order(id),
> ) inherits (file_attachment);
>
>
While I
Ok
So what I am trying to do is:
1) Paritioned tables
2) Joins against the table partitions
The way I have this done is:
The first table is partitioned on the basis of one part of the primary
key. So in theory since nobody has permission to insert into the base
table, all records should have
On Jul 9, 2011, at 9:21, Chris Travers wrote:
> On Sat, Jul 9, 2011 at 6:09 AM, Guillaume Lelarge
> wrote:
>
>>
>> To have a primary key or a unique key on an partitioned table, it would
>> mean that we should be able to have one index on multiple tables.
>> Because primary key and unique cons
On Sat, Jul 9, 2011 at 6:09 AM, Guillaume Lelarge
wrote:
>
> To have a primary key or a unique key on an partitioned table, it would
> mean that we should be able to have one index on multiple tables.
> Because primary key and unique constraints are enforced with an index.
> That's not something
On Sat, 2011-07-09 at 05:59 -0700, Chris Travers wrote:
> Hi all;
>
> I started trying to use table partitioning to handle a rather odd case
> in the software I am working on. I ran into an issue (one I can
> correct in my code) that strikes me as extremely unintuitive. I
> figured I would repor
Hi all;
I started trying to use table partitioning to handle a rather odd case
in the software I am working on. I ran into an issue (one I can
correct in my code) that strikes me as extremely unintuitive. I
figured I would report it here as behavior I would like to see change.
The basic problem
On 9/07/2011 8:26 PM, pasman pasmański wrote:
Reality is crude, seems than this idea is not as good as i think :(
Thanks for answer.
No worries.
For what it's worth, PostgreSQL caches recently used tuples in shared
memory anyway. The OS caches disk data in RAM too. So if the foreign key
is
Reality is crude, seems than this idea is not as good as i think :(
Thanks for answer.
2011/7/9, Craig Ringer :
> On 9/07/2011 3:06 PM, pasman pasmański wrote:
>> Hi.
>>
>> Today i have an idea for increase performance of foreign keys. After
>> search parent record, store ctid in shared memory.
On 9/07/2011 3:06 PM, pasman pasmański wrote:
Hi.
Today i have an idea for increase performance of foreign keys. After
search parent record, store ctid in shared memory. Subsequent searches
look first to the record at stored ctid, and when it is deleted do
regular search using index.
How many
On 9/07/2011 2:39 PM, Darren Duncan wrote:
What if you used the context of the calling code and resolve in favor of
whatever match is closest to it?
*BAD* idea IMHO.
It sounds attractive at first, but inevitably leads to problems where a
query used to work until someone creates a table/type/w
On 9/07/2011 11:27 AM, Robert Haas wrote:
On Fri, Jul 8, 2011 at 2:21 AM, Darren Duncan wrote:
I think an even better way to support this is would be based on Postgres
having support for directly using multiple databases within the same SQL
session at once, as if namespaces were another level d
Hi.
Today i have an idea for increase performance of foreign keys. After
search parent record, store ctid in shared memory. Subsequent searches
look first to the record at stored ctid, and when it is deleted do
regular search using index.
Pro: faster searching for common keys when parent table is
On Fri, 2011-07-08 at 21:04 -0700, Darren Duncan wrote:
> > I think you should make more of an effort to understand how the system
> > works now, and why, before proposing radical redesigns.
>
> Well yes, of course. But that will take time and I think I already
> understand
> enough about it to
21 matches
Mail list logo
