From: | Steve Crawford <scrawford(at)pinpointresearch(dot)com> |
---|---|
To: | Radcon Entec <radconentec(at)yahoo(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Table has 22 million records, but backup doesn't see them |
Date: | 2009-04-08 19:15:05 |
Message-ID: | 49DCF7B9.50409@pinpointresearch.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Radcon Entec wrote:
> ------------------------------------------------------------------------
> *
> *
> You are, of course, correct. "select count(*) from only feedback"
> returns 0. I have never used (or even seen) PostgreSQL rules before.
>
> When I run the query "select * from feedback where charge = 23017", I
> get 538 records. Adding the word "only" gives me zero records, as
> expected, and querying the feedback_active table gets me my 538
> records. But the feedback table only has the INSERT rules you quoted
> above. I clicked on the feedback table's Rules leaf and selected "New
> Rule", and saw that I can create SELECT, INSERT, UPDATE and DELETE
> rules. But even though I don't have a SELECT rule explicitly defined,
> PostgreSQL appears to be smart enough to retrieve data from the
> correct actual table when I think I'm selecting from the feedback
> table. Is that standard behavior?
>
> Of course, my next step will be to read the documentation.
>
You won't find the cause of your surprise reading up on rules. Read up
on inheritance, instead. It can do a lot, but a typical simple use is
table-partitioning as appears to be the case in your situation.
You start with the main (parent) table, say "events" then create a bunch
of child tables that inherit events, say events_jan, events_feb,
events_mar...
You never put actual data in "events" but create a rule or trigger that
looks at the month information and puts January events in events_jan,
February in events_feb and so on.
Select * from events is more-or-less equivalent to:
select * from events_jan union
select * from events_feb union...
Inheritance goes far beyond the simple case shown above. There's a lot
of nifty stuff you can do and a number of things that can bite you. But,
as you say, that's where the documentation comes in.
Cheers,
Steve
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Mayo | 2009-04-08 19:30:28 | Re: Are there performance advantages in storing bulky field in separate table? |
Previous Message | Robert Treat | 2009-04-08 19:13:27 | Re: Are there performance advantages in storing bulky field in separate table? |